nuthatch

Latest ship

Builder activity

Build timeline

1. Active development: 82 commits across 1 contributor

   2d ago

   Code Activity · Source linked

   7 active day(s) in nightswatchhq/nuthatch.

   View evidence

2. v3.6.1

   2d ago

   Github Release · Source verified

   One fix, on a defect that had two production nests reporting perfect health while the watermark their receipts pin had not moved in two days. A bug fix; the freeze stands. The implementation landed in #1200, on issue #1199. A sparse nest stopped sealing, and nothing said so (#1199) Segments are cut once enough rows have finalised. On a nest whose contracts are quiet that threshold can take months to reach, and until 3.6.1 the sealed watermark simply waited: a finalized range carrying too few rows was held, the range only grew, and the shortcut that carries the watermark across a stretch wit

   View evidence

3. Active development: 82 commits across 1 contributor

   2d ago

   Code Activity · Source linked

   6 active day(s) in nightswatchhq/nuthatch.

   View evidence

4. v3.6.0

   3d ago

   Github Release · Source verified

   The release that makes a dashboard cheap to serve. Two things the Lodestar cutover measured on 2026-09-06, both performance, neither a new capability; the freeze stands. A deterministic memo for repeated /sql statements (#1186) The dashboard's heaviest views are whole-history folds recomputed on every request: after 3.5.1 the allocations nest still spent 89 s answering its 47 distinct statements serially, 42 s of it in four. Those statements repeat, and between repeats nothing they read has usually changed. A /sql answer is a function of its inputs, so the nest now remembers answers und

   View evidence

5. v3.5.1

   3d ago

   Github Release · Source verified

   A patch for the two things the Lodestar cutover found on 2026-09-06. Every nest serving more than one SQL permit should restart onto this; nothing changes on disk. Concurrent /sql execution segfaulted the nest (#1165) Twenty-five segfaults a minute at four permits under the dashboard's load, three an hour at two, none at one. The cause was not memory. Every DuckDB instance a process opened - and the analytical path opens one per concurrent query, because the connection cache lends its connection out for the query's duration - spilled to the same default temp_directory, .tmp under the

   View evidence

6. v3.5.0

   4d ago

   Github Release · Source verified

   The release that turns the RPC bill down. Every nest following a chain tip should restart onto this with a --poll-interval matched to how often anyone reads it; nothing changes on disk. The freshness dial: --poll-interval and --finality-only (#1173, RFC-0040) Measured on a nest at tip against a paid endpoint on 2026-09-06: 268 block headers, 61 log requests and 84 tip polls a minute, about 9,900 compute units a minute, roughly $185 a month. Of that day's 345,600 Arbitrum blocks, 95 carried an event the nest wanted. The code already bought headers only for those; the rest was the poll

   View evidence

7. Active development: 81 commits across 1 contributor

   4d ago

   Code Activity · Source linked

   5 active day(s) in nightswatchhq/nuthatch.

   View evidence

8. v3.4.1

   4d ago

   Github Release · Source verified

   Three things found on one afternoon of running a fresh 3.4.0 nest behind a live dashboard. Every nest serving queries should restart onto this; nothing changes on disk. A query no longer fails when a seal replaces a segment under it (#1162) A seal folds a provisional segment: the new file is written, the manifest installed, the old file removed. A query that planned against the old manifest a moment earlier was still holding the old name, and DuckDB failed it at prepare (No files found that match the pattern) or at execution (Cannot open file). Three of about forty queries did this in o

   View evidence

9. Active development: 80 commits across 1 contributor

   4d ago

   Code Activity · Source linked

   4 active day(s) in nightswatchhq/nuthatch.

   View evidence

10. v3.4.0

    5d ago

    Github Release · Source verified

    Sparse tables stop fanning out into one tiny file per seal cut, and Robinhood Chain is built in. A nest with many tables should restart onto this; a nest with a handful gains nothing from it. A sparse table no longer gets a Parquet file per cut (#1150) The seal cut is global and data-determined: every 20,000 rows across all of a nest's tables, at a block boundary the chain chose. Until now every table with rows at that cut got its own segment file, however few rows it had. On a nest with two hundred tables that is a file per table per cut, and most of them are tiny. Measured on the Perpl ne

    View evidence

11. v3.3.1

    6d ago

    Github Release · Source verified

    One fix, to what every nest asks for and seals. Worth the restart. A short answer can no longer seal as an empty block (#1144) Every way a provider answers a log range short lands at the end of the range: a load-balanced backend a block or two behind the one that answered latest, a height a node has finalised but not yet executed (Monad), an answer truncated under load. All of them answer correctly a moment later, and all of them return a list, which is a valid answer. So the rows were sealed as an empty block, into immutable Parquet, with nothing to say they were missing, and the block's

    View evidence

12. v3.3.0

    6d ago

    Github Release · Source verified

    A new built-in chain, and a fix to the front door. A nest already running gains nothing from restarting; anyone about to run nuthatch init for the first time should use this release. Monad is built in (#1136, RFC-0051) nuthatch init 0xADDR --chain monad works with no key and no --rpc. Chain id 143, a full-EVM L1 with MonadBFT single-slot finality, blocks every 300 ms, on the generic EVM path: a registry entry, not an adapter. The freeze was lifted for this one chain and nothing else; it is carve-out three in the brief, and the Robinhood Chain draft stays frozen. **What an operator sho

    View evidence

13. v3.2.0

    6d ago

    Github Release · Source verified

    Two changes to the binary, one of which an operator should read before restarting, and a good deal of tooling around the edges. No security driver this time. The tip path batches its seals (#1067) The backfill path has long accumulated 20,000 rows and cut a segment at a block boundary chosen from the data. The tip path did not batch at all: it sealed whatever had just finalised, which at tip is a few blocks carrying a few rows, and each became its own Parquet file. The result was bimodal. horizon-nest reached 11,763 segment files at a median of 6.3 KB, 80% of them under 20 KB, and every a

    View evidence

14. v3.1.0

    9d ago

    Github Release · Source verified

    A security update, two production defects that only measurement could have found, and a sprint's worth of gates that turned out not to be gating anything. Security wasmtime 46.0.3 - RUSTSEC-2026-0268 and RUSTSEC-2026-0269. Reason enough on its own to take this release. Two defects that were live in production Both were invisible to code-reading and obvious the moment anything was measured against a running nest. Both are the same shape - a surface reporting something the system did not believe. tip_lag_blocks read 0 on a nest that was behind (#1020). The gauge was written from

    View evidence

15. v3.0.1

    11d ago

    Github Release · Source verified

    A one-line fix to a metric, and a great deal of measurement that changed what we believe about our own system. Nothing in the data path moved. The fix nuthatch_sealed_through reported 0 after every restart while the query path knew the true watermark all along. The gauge was only ever written when a seal happened, so between a restart and the next seal /metrics said 0 and /sql provenance said the truth. Two surfaces disagreeing about one fact, and the wrong one is where Prometheus looks. It has always done this - a 2.7.1 nest restarted alongside a 3.0.0 one behaves identically - b

    View evidence

16. v3.0.0

    12d ago

    Github Release · Source verified

    Authored incremental entities, stable. A nest declares a relation in entities.toml and nuthatch maintains it as blocks arrive instead of recomputing it on every query. That is RFC-0041, and it is what the major bump is about. 3.0.0-alpha.1 carried the feature; this carries it plus what a day of soaking it on real chains found. Drop-in, with one sentence of small print Replace the binary and restart. No config migration, no data migration, no re-index. A nest that declares no entities behaves exactly as it did on 2.7.x. Verified on production data: all 73 tables of the Lodestar Horizon n

    View evidence

17. v3.0.0-alpha.1

    12d ago

    Github Release · Source verified

    A nest can declare a relation in entities.toml and nuthatch maintains it as blocks arrive, instead of recomputing it on every query. That is RFC-0041, and it is what the major bump is about. This is an alpha, and it is an alpha for a reason. The endurance evidence is thin and still accumulating: at the time of this cut an entity had followed a chain for twenty hours without falling behind, and no process carrying one had been restarted after days of uptime. docs/releases/3.0.0-alpha-stresstest.md says what is still unanswered and in what order it gets answered; `docs/bench/3.0.0-alpha-

    View evidence

18. nuthatch 2.7.2

    16d ago

    Github Release · Source verified

    A patch release for the operational work that landed after 2.7.1. Drop-in. Replace the binary and restart. There is no config migration, data migration, or re-index. Bounded runtime state and honest metrics The runtime now bounds and evicts its DuckDB connections as mounts change, rather than keeping a connection for every nest that has ever appeared. Departed nests also leave the process-wide metrics registry. This keeps a long-lived multi-nest process from retaining dead state indefinitely. Metrics no longer publish arbitrary cross-chain values as a global tip or lag. The process-wide ser

    View evidence

19. v2.7.1

    17d ago

    Github Release · Source verified

    A fix release. 2.7.0 was the binary an evaluator actually ran, and it lied in four places that matter: --rpc still dialled public endpoints, /ready was green on a dead pool, init of stETH scaffolded a nest that would index nothing, and an oversized ethgetLogs range retried forever. Drop-in. Swap the binary and restart; no config changes, no data migration. --rpc is the whole pool Passing --rpc used to *prepend* your endpoint to the bundled public defaults. init wrote all of them into rpcurls, and dev --rpc still failed over onto nodies and drpc. A paid-only run was neith

    View evidence

20. v2.7.0

    18d ago

    Github Release · Source verified

    A nest that declares [[calls]] can use --seal-direct again, a factory nest stops aborting its backfill on a provider cap, and this page stops quoting performance numbers it cannot stand behind. Drop-in. Swap the binary and restart; no config changes, no data migration. A minor rather than a patch for one reason: 2.6.x refused --seal-direct on a nest with [[calls]] and 2.7.0 does not. That is new behaviour on an existing surface, and calling it a patch would be the small dishonesty this release is otherwise about. A factory nest no longer dies on a provider cap uniswap-v2 on ma

    View evidence

21. v2.6.3

    19d ago

    Github Release · Source verified

    The first run stops stalling. If you tried nuthatch on Ethereum mainnet and concluded it was broken, it was, and this is the release that fixes it. Drop-in. Swap the binary and restart; no config changes, no data migration. A first run on mainnet no longer stalls Point nuthatch init at a contract, run nuthatch dev, and on 2.6.2 you would get 15 events in 90 seconds - or, behind a provider that refuses without explaining itself, no progress at all, forever. The window controller grows fourfold on an empty range. An empty range says nothing about capacity, so from a 1,000-block start

    View evidence

22. v2.6.2

    20d ago

    Github Release · Source verified

    The front door. No new capability - a feature freeze runs to the end of 2026 (docs/roadmap-2027.md) - and this release is the first instalment of what replaces it: making the parts a stranger meets first actually good. Drop-in. Swap the binary and restart; no config changes, no data migration. --help no longer opens with a fleet orchestrator Twenty-four subcommands, ordered by when each was added, with worker and control - a writer pool and a control-plane API - ranking fifth and sixth, above sql. A solo dev reading top to bottom met cursor leases before

    View evidence

23. v2.6.1

    20d ago

    Github Release · Source verified

    A fix release. Two faults found by running 2.6.0 against production data rather than by reading it, one of which will bite anyone who takes up the [[calls]] feature 2.6.0 introduced. No new capability, no config changes, no data migration. Swap the binary and restart. A transient RPC failure no longer kills a nest (#651) The one to upgrade for. On 2.6.0, a single dropped connection during a pinned ethcall ends the process: INFO backfilling 87.6% - block 440066152 of 496262427, 1178466 events, 248 ev/s Error: pinned ethcall batch at block 440200000 Caused by: transport error: error

    View evidence

24. v2.6.0

    21d ago

    Github Release · Source verified

    The release that closes subgraph parity. A nuthatch nest can now do the two things a subgraph could and a nest could not: call a contract, and read a document off IPFS. Four new chains, and two silent-wrong-answer fixes found by running the new code against production data rather than against fixtures. Derived from git diff v2.5.0..main and from the live runs described below, not from PR titles. Contract calls: [[calls]] (RFC-0023 tier 3, #262) A nest can pin a contract read to a block and store the result as a table. [[calls]] name = "grttotalsupply" contract = "0x9623063377A

    View evidence

Research notes

Written by Dawnscan researchers and reviewed before publishing. Commentary with sources — not the project's own claims, and not evidence of shipping.

No published notes on nuthatch yet.

Know something about nuthatch? Sign in with wallet to submit a research note. Notes are reviewed before they appear here.

Sources

• https://nuthatch-indexer.com/Unverified
• https://github.com/nightswatchhq/nuthatchOfficial