rotki
Your accounts' history, from your own machine
The rotki integration is a PR awaiting review, for
transactions, internal transactions and token transfers on every EVM chain a nest serves. It needs Nuthatch 5.6.0 or later.
To try it before the PR is merged, run rotki from that PR’s branch; these settings are not in a released rotki version.
rotki asks a block explorer for every transaction, transfer and withdrawal of every account you track,
which means a third party learns all of your addresses. A rotki-mode nest answers the same questions locally.
It watches only the accounts you give it, reads the chain over your own RPC, and serves the answers at
/api in the shapes rotki already understands. rotki falls back to its next indexer for anything
the nest has not fetched, so it never reads a gap as an empty history.
One nuthatch.toml naming Ethereum, your RPC, an account and where history starts. No contracts, no SQL, no Docker.
nuthatch dev backfills the accounts, then checks the chain every five minutes. A trace RPC is needed for internal transactions.
Under RPC Nodes, the Nuthatch nest tab takes the nest's address. Put Nuthatch first in the indexer order of each chain the nest serves, and rotki registers your accounts on those chains with the nest itself. Select Nuthatch alone if you want history requests to stay with your nest; otherwise the next configured explorer can receive your address when coverage is incomplete.
[nest]
name = "rotki"
chain = "mainnet"
chain_id = 1
rpc_urls = ["https://your-ethereum-rpc"]
[address_history]
addresses = ["0xYourAccount"] # rotki adds the rest of your accounts itself
start_block = 17030000 # history before this is never fetched; 0 means genesis, which takes hours
poll_interval = "5m"
mev_relays = true # produced blocks and their MEV, from the relays; they see block numbers
# validators = [123456] # list them here for now; proofs run from block 23,551,570
# beacon_url = "http://127.0.0.1:5052" # build validator proofs beyond the published catalogue
# optional: verified partitions instead of one RPC call per block
[address_history.mirror]
url = "https://nestsss.nestsss-worker.workers.dev"
chain_id = 1
from_block = 17030000
cache_mb = 2048curl -fsSL https://nuthatch-indexer.com/install.sh | sh
export NUTHATCH_TRACE_RPC=https://your-trace-rpc # kept out of the process list
nuthatch dev --dir rotkicurl 'http://127.0.0.1:8288/api?module=account&action=txlist&address=0xYourAccount&startblock=17030000&endblock=17100000'Checked against Etherscan
vitalik.eth on Ethereum, blocks 18,000,000 to 20,000,000: every row compared field by field with Etherscan's answer, and the set of transactions below matched exactly. Internal transactions, withdrawals, block rewards and relay deliveries were checked the same way on pinned cases. Run end to end with the earlier integration branch over blocks 17,040,000 to 17,300,000, rotki with Etherscan removed from its indexer order produced the same 557 transactions and 579 decoded events as rotki with Etherscan alone, and made no request to Etherscan.
- txlist
- 2,318 transactions
- tokentx
- 3,334 transactions with token transfers
- tokennfttx
- 106 transactions with NFT transfers
- token1155tx
- 53 transactions with ERC-1155 transfers
- getblocknobytime
- 20 of 20 timestamps
Light to run
The nest runs on its own small path, beside the indexer's event pipeline rather than inside it. On an M-series Mac it starts serving in well under a second.
An ordinary wallet with 1.19 million blocks of history, measured on 2026-10-14 over a hosted RPC with 5.3.2's defaults: about 20 minutes to backfill, 7,324 RPC calls, and a 2.5 MB index. Block bodies are read only for an account rotki asks withdrawals or produced blocks about, which it does only for a tracked validator's address.
What leaves your machine
Your RPC sees the queries it always would. The partition mirror, if you name one, sees your IP and the block ranges
it serves, never an address. The MEV-Boost relays are asked only if you set mev_relays = true,
because the block numbers they are asked about identify a validator.
Validator coverage
Proven validator blocks begin at execution block 23,551,570. Earlier proposals remain outside the catalogue.
The published catalogue advances in complete 10,000-block spans. Set beacon_url to your beacon node
to prove the tail beyond it; without a beacon endpoint, the nest reports that tail as incomplete until publication.
Account history before start_block remains uncovered, and rotki shows the gap.
rotki's existing free-account validator ownership limits still apply. The nest serves withdrawals and produced blocks
already, but rotki does not ask it for them yet: the PR covers transactions, and validators will follow in a later one.
Six more chains, no explorer key
From 5.5.0 a nest serves account history on Optimism, Base, Arbitrum, Polygon, BNB Chain and Gnosis, the chains
rotki users are otherwise asked to buy explorer keys for. It finds outgoing transactions where the account's nonce
rises and incoming value where its balance rises past its own spending, and traces only those blocks, so the trace
RPC must serve debug_traceBlockByNumber. Every traced block must balance to the wei or it is not served.
It proves an ordinary account. A contract, or an account with EIP-7702 delegated code, answers unsupported from the block it gained code, so rotki asks its next indexer. An incoming transaction that moves no value is not listed. Checked against Blockscout on Optimism, Arbitrum and Gnosis, every field identical.
rotki takes one nest address, and from 5.6.0 one address serves several chains. Make a directory with one
subdirectory per chain, each holding its own nuthatch.toml, and run nuthatch dev --dir on the
directory. Each chain keeps its own cursor and store and answers the calls whose chainid names it. Each
reads its RPCs from NUTHATCH_RPC_<chain id> and NUTHATCH_TRACE_RPC_<chain id>, or its
own rpc_urls. With Nuthatch first in Gnosis's indexer order, rotki produced the same 82 events from
the nest alone as from Blockscout and Etherscan.
Partitions you can check
The hosted Ethereum partitions carry every header and withdrawal since Shanghai. Your nest hashes each header, links it to its parent, anchors the run to a finalized block from your own RPC and recomputes each withdrawals root, so a bad file is refused, never served.