Stories

Who runs Nuthatch

Nuthatch has three front doors: an SQL endpoint for application backends, published nests for people who want data without writing indexing code, and a built-in MCP server for agents. Same binary, same data, one process on your own hardware.

Illustrative workflows, not customer stories — Nuthatch is pre-release.

These workflows describe the product as designed. They are written in the present tense for readability. Today the binary indexes ERC-20 Transfer events across one or more contracts on a single chain, maintains a balance view incrementally, and serves read-only SQL and MCP; multi-contract init and the MCP server work now. User-authored views, init --from, non-Transfer decode, and other chains are design targets — see the quickstart for what runs today.

A dapp backend

Maya's three-person team runs a lending protocol on Arbitrum. The frontend needs user positions, borrow history, and a few protocol-wide stats — the read side of the app, the part a managed indexer usually bills for.

She points one command at the protocol's contracts and runs it on a €15 VPS. Nothing else to provision: no Postgres, no queue, no second box.

nuthatch init --chain arbitrum-one \
  0x1F98431c8aD98523631AE4a59f267346ea31F984 \
  0xC36442b4a4522E871399CD717aBDD847Ab11FE88

Every event in those ABIs becomes a queryable table as the backfill streams through history, so she can read the raw layer before modelling anything. The positions her frontend needs are one declarative view over deposits and withdrawals:

create view positions as
select user_address,
       sum(case when kind = 'deposit'  then amount else 0 end)
       - sum(case when kind = 'withdraw' then amount else 0 end) as net_supplied
from (
  select user_address, amount, 'deposit'  as kind from deposit
  union all
  select user_address, amount, 'withdraw' as kind from withdraw
)
group by user_address;

Her API route calls POST /sql the same way it would call Postgres — one read-only endpoint on localhost, no driver to install, no connection pool to babysit:

curl -s http://127.0.0.1:8288/sql \
  -H 'content-type: application/json' \
  -d '{"query": "select net_supplied from positions where user_address = $1", "params": ["0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D"]}'

When Arbitrum reorgs, the affected rows retract and anything derived from them corrects itself; the frontend never sees the wobble.

What she stopped doing: paying per entity for her own application's data, and trusting a third party's uptime for a read path she now runs herself.

A dashboard, no indexing code

Petar delegates GRT and wants one thing: to see which Graph Horizon indexers actually earn. He does not want to write handlers, and he does not need to.

He pulls a published nest — contracts, vendored ABIs, and derived views all included — and runs it against his own node. He wrote no indexing code; he ran someone else's definition:

nuthatch init --from https://github.com/example/horizon-nest

From there the data is just SQL. One query drives a Grafana panel, or a bare HTML page with a single fetch:

select * from indexers order by total_rewards_earned desc limit 20;

The point is that a nest is a shareable indexing definition, not a hosted feed: he ran it on his own hardware and can read every line of what produced the numbers.

Derived views read finalized data; the raw event tables are fresh to the tip. A dashboard built on views trails the chain head by finality — the honest trade for numbers that never retract under you.

An agent, locally

Dana builds a DeFi assistant. She wants it to answer questions about on-chain data without shipping that data — or her users' questions — to anyone.

She adds Nuthatch to the agent's MCP config. That is the whole integration:

{
  "mcpServers": {
    "nuthatch": { "command": "nuthatch", "args": ["mcp"] }
  }
}

The agent discovers the schema itself through the schema tool and composes queries through the sql tool, so when her user types "which indexers grew delegation fastest this month?" it writes the query rather than guessing the shape.

Nothing leaves the machine: no API key, no per-query bill, and it works offline against the local instance.

The pattern across all three: nobody deployed to someone else's platform, nobody got an API key, and nobody's story ends with a monthly invoice. To a frontend, Nuthatch looks like a fast read-only database that fills itself from the chain and heals itself through reorgs. GraphQL is on the roadmap for subgraph-shaped clients.

Try the quickstart See the full example