Docs

Connecting a node or Electrum server

A wallet has to get its information from somewhere: which coins are yours, what has arrived, what fee to pay. Most wallets come with public servers already set up to answer that.

Shrike does not, and that is deliberate. The public ones are still following the old rules, so they would be answering about a different chain than the one you are spending on. Rather than ship defaults that look like they work and quietly mislead you, Shrike ships none and asks you to point it at something you trust.

There are two ways to do that, both below: connect it straight to your own Bitcoin Knots node, or run your own Electrum server in front of that node. Either way the node has to be a recent enough Knots.

Bitcoin University has a video walkthrough of setting this up, covering Start9 and Umbrel and installing Shrike against them. It is a community recording made before the current release.

Why run your own

A server you connect to sees which addresses you ask about. That is enough to tie your balance, your transaction history and your future payments together, and to tie all of it to your IP address. Running the node yourself is what stops that from being someone else's record.

How much it stops depends on which of the two arrangements below you pick, and they are not equivalent:

• Your own node, connected directly. Nothing about your wallet leaves your machine. The tradeoff is that the node keeps your balances, transactions and public keys on disk unencrypted, so it is a poor host for keys you are treating as cold storage.
• Your own Electrum server in front of your own node. The most private of the two. An Electrum server indexes every transaction on the chain equally, so nothing it holds marks your wallet's transactions out from anyone else's, and it discards your queries once it has answered them.

Either beats a server someone else runs, which is most of why the preconfigured ones are gone.

Why the public servers are gone

A server that did not take the upgrade stops following the chain at the activation height and carries on under the pre-fork rules. Point Shrike at one and it reports a history that ends there, prices fees against a mempool you are not broadcasting into, and judges transactions by rules Shrike is not following. Rather than leave working-looking but wrong defaults in the settings, the fork removes them.

Fee rates, block explorer links and broadcast all go to mempool.guide, which has adopted the fork, and over Tor where a proxy is configured.

Option 1: a Knots node

Connecting Shrike straight to a Bitcoin Knots node at v29.4.1.knots20260508 or later is the simplest arrangement, and the only one where the activation height gets cross checked: Knots reports it through getdeploymentinfo, and Shrike compares that against its compiled-in height. If the two disagree the wallet declines to opt in rather than choosing a side.

In Settings → Server, choose the Bitcoin Core server type and point it at your node's RPC. Shrike will import and scan wallets through the node directly. The status bar turns green once it connects.

The server type is named Bitcoin Core, but the node behind it has to be Knots. That label is inherited from upstream and describes the RPC interface, not the software you have to run. Bitcoin Core itself stays on SHA256d and does not follow the fork, so pointing Shrike at one gives you a node that stopped at the activation height.

If your node was pruned before the fork it may stall rather than follow the new work, and recovering can mean redownloading the chain. Check that it is past the activation height and following BLAKE2b before relying on it.

Option 2: your own Electrum server

An Electrum server indexing a node at v29.4.1.knots20260508 or later is the more private arrangement, and the faster one: scanning a large wallet through a node directly is slow, and an index makes it quick. It has to be your own, or one you know follows the fork. Configure it under Settings → Server as a private Electrum server, and the status bar turns blue once it connects.

Stock Fulcrum will not do. It validates SHA256d headers, so it stops at the activation height like any other unmodified software. Builds with BLAKE2b support are published here:

• Fulcrum with BLAKE2b support, for a server you run yourself
• the same, packaged for StartOS
• electrs with BLAKE2b v2 header support, if you prefer electrs to Fulcrum; source only, no published builds

Both are unofficial forks and neither is audited, on the same terms as Shrike itself.

Behind a server that does not report an activation height, Shrike still opts in when it signs, and tells you the height went unchecked rather than staying quiet about it.

Networks

Shrike runs on mainnet, testnet, testnet4, regtest and signet. Select one at launch:

./sparrow --network testnet4

The environment variable SPARROW_NETWORK is honored as a fallback, and is still spelled that way because the fork did not rename it. Whichever you use, the server you connect to has to be running on the same network.

Configuration and wallets for the non-mainnet networks are kept in subfolders of the home folder, so switching networks does not disturb a mainnet setup.