nuthatch

Roadmap

Roadmap

Nuthatch plans in public. The work is numbered as RFCs in the repository, the progress log carries one entry per push, and the load-bearing claims come with a measured number rather than a promise. This page is the map over that ground.

The reading key is plain. Shipped means merged with tests and, where it matters, a measured number. In progress means partially landed, with the remainder tracked. Planned means an RFC written in the repository, not yet started. Not planned means exactly that. Dates are not promised — order is.

Shipped

The embedded single-binary pipeline, end to end

  • init resolves each contract ABI (Sourcify, then an Etherscan-class API, with EIP-1967 and legacy-OZ proxy resolution) and scaffolds the nest.
  • Deterministic decode of every declared event of every contract — a topic0-keyed registry, one table per {alias}__{event}.
  • Reorg self-healing: block-hash checkpoints roll the hot store back; a proptest asserts convergence with the winning branch.
  • Finality-gated, content-addressed Parquet sealing, with the hot store pruned once every table's segment is durable.
  • Read-only analytical SQL over sealed segments (DuckDB), plus GET /tables and GET /table/{name} merging hot and cold.
  • Balance view maintained incrementally (DBSP): i128 base units, a reorg is a retraction, and it replays from stored facts on restart.
  • Serving over HTTP and MCP: the MCP server speaks stdio with 8 tools, fully offline.

Nests

  • init --from <git-url | ./dir> — a nest is a git repo, so there is no registry; the vendored ABIs and deployment blocks travel with it.
  • A schema-version guard rejects a nest declaring a newer format, which is what makes consuming a third party's nest safe.
  • views/*.sql derived entities load in sorted filename order over the per-event tables.
  • nuthatch check runs a nest's checks/*.sql against recorded fixtures — the generic parity and invariant framework, hermetic in CI.

Chains

  • Ethereum mainnet (64-block depth finality) and Arbitrum One (chain 42161), the L2 reading its L1-aware finalized tag with a depth fallback — finality is a data-entry policy, not a fork of the loop.

Backfill throughput, measured

  • nuthatch bench backfill reports the median of events per second, wall-clock, peak RSS and RPC requests; every published number traces to a report artifact.
  • Seal-direct plus pipelined fetching moved a fixed USDC workload from ≈289 to 2,521 to 5,837 events/sec on public RPC — about 20× over the redb baseline.
  • Path-equivalence holds: a given block range yields byte-identical segments regardless of the storage path, proven by test.

WASM transforms

  • Pure wasm32-wasip2 components load with zero capabilities, so purity is checkable from a component's imports alone; the call boundary is a whole Arrow batch.

CI and footprint

  • A CI footprint job fails the build above 256 MB of RAM.
  • Measured peak: ≈37 MB for a single contract, ≈58 MB across a three-contract, 23-table nest — 2.8% of the 2 GB budget.

In progress

  • reth ExEx wiring (RFC-0003): the Source trait, the library split, and the push-to-pull bridge are in and tested, and the toolchain and reth dependency-resolution blockers are cleared. Wiring the ExEx needs a synced node.
  • The Horizon nest (RFC-0002): three real Arbitrum contracts with derived views compute on live data (390 active allocations, 5 indexers, 70,030 GRT in rewards). The remaining work is full parity against the deployed subgraph through nuthatch check fixtures.
  • Backfill throughput (RFC-0004): the bench harness, seal-direct, and pipelined fetching have landed; adaptive chunking and the own-node tier numbers remain.

Planned

  • RFC-0005 — release engineering for v0.1.0: signed artifacts, a real install.sh, a published crate, and a Homebrew tap. This is what makes the install command on this site end-to-end true for a stranger on a fresh machine.
  • RFC-0008 — the compliance pack: list-as-data screening kept out of the data path, retraction-correct flags, direct exposure, and audit-grade reproducibility. So a stablecoin or fintech operator can replay every decision.
  • Scaled mode (RFC to come) — a Postgres hot store and DataFusion federating hot and cold behind one SQL surface.
  • Effectful transform worlds with signed pipeline manifests (RFC to come) — outputs are append-only annotations, never mutations of core entities.
  • A governed semantic layer with natural-language queries (RFC to come) — the model reads a schema, not a guess.
  • A GraphQL compatibility layer (RFC to come) — for subgraph-shaped clients.
  • IVM generalisation (RFC to come) — derived views are DuckDB SQL over sealed data today.
  • Multi-chain beyond mainnet and Arbitrum One (RFC to come).
  • Factories and dynamic contract discovery (RFC to come) — for Uniswap-class protocols; a candidate for the v0.1 gate.
  • A local admin UI and webhooks (RFC to come) — sealed-by-default deliveries with honest retractions.
  • Wildcard, signature-scoped indexing and the open-lakehouse docs (RFC to come) — your warehouse reads the Parquet directly, with no ETL step.

RFC-0006 (grant funding) and RFC-0007 (launch and validation) track how the project sustains itself and goes public — process, not product.

Not planned

  • A token or decentralized-network features.
  • Telemetry of any kind.
  • A Kubernetes-first deployment.

These are design decisions, not gaps — the project's scope rules explain why.

The progress log in the README is the change-log of record, and it moves faster than this page. Where this page and the log disagree, trust the log — and read the RFCs for the reasoning behind each line.