Bellchain
by bellchain-app
Crypto alert chains in your AI assistant: check alerts, test ideas with the replay, build chains.
Runs on your computerUpdated today
Install
nuthatch
Overview
Description from the maker (original English)
Query an EVM contract's indexed history with SQL, via a local nuthatch nest and nuthatch dev.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiNot measured yet★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Crypto & blockchain
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- The registry lists no key to fill in.
You need
- DockerDocker installed
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"nuthatch": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/nightswatchhq/nuthatch:4.0.0",
"mcp",
"--url",
"http://host.docker.internal:8288"
]
}
}
}Run this in your terminal
claude mcp add nuthatch -- docker run -i --rm ghcr.io/nightswatchhq/nuthatch:4.0.0 mcp --url http://host.docker.internal:8288Or copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"nuthatch": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/nightswatchhq/nuthatch:4.0.0",
"mcp",
"--url",
"http://host.docker.internal:8288"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"nuthatch": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/nightswatchhq/nuthatch:4.0.0",
"mcp",
"--url",
"http://host.docker.internal:8288"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 7, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account nightswatchhq, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Crypto & blockchaini
- More stars than 0% of the other 1611 servers in this category
- Published to the registry more recently than 56% of the other 1611 servers in this category
- Basic checks equal to or better than 100% of the other 1611 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is nuthatch safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (4.0.0) reached the registry 37 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Docker on your computer.
What can I use instead?
In the same category: Bellchain, Quidli Connect, Diamond Bitcoin Intelligence
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Quidli Connect
by Quidli
Resolve social handles to wallets, score onchain reputation, pay in any ERC-20, SPL or native.
Computer or cloudUpdated today
Install
Diamond Bitcoin Intelligence
by diamond.btc-intel.workers.dev
Bitcoin MCP: fee budgets, retained-block inclusion proofs and risk checks. Free service discovery.
Runs in the cloudUpdated today
Install
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
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 | shexport 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).
| Needs a subgraph | Needs handler code | Data comes from | What you run | Query with | |
|---|---|---|---|---|---|
| The Graph | yes | yes (AssemblyScript) | indexers on the network | nothing, or graph-node + Postgres + IPFS | GraphQL |
| Ponder | no | yes (TypeScript) | your RPC endpoint | Node.js, plus Postgres in production | SQL, GraphQL |
| nuthatch | no | no: tables come from the ABI | your RPC endpoint | one binary | SQL, HTTP, MCP |
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 0xAddrresolves 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 | shThat 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 referenceshypotatGLIBC_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/nuthatchFrom source, which is the only route on a platform we do not publish a binary for:
rustup toolchain install 1.95.0cargo +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.exampleThe 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;
/readyreportsstalledwhen 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 0xADDRUse 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/arbitrumnuthatch 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
Only the beginning is shown; read the rest in the repo