Docs

Building and running Shrike

Build requirements are unchanged from upstream. The one thing to get right is the recursive clone.

Clone

Clone this repository rather than upstream's, and --recursive matters: the BLAKE2b work lives in the drongo submodule, and a flat clone will not build.

git clone --recursive https://github.com/privkeyio/shrike.git

When updating later:

git pull --recurse-submodules

Requirements

Java 25 or higher. The release binaries are built with Eclipse Temurin 25.0.2+10; with SDKMAN, sdk env install picks up the right version. On Debian and Ubuntu, packaging also needs:

sudo apt install -y rpm fakeroot binutils

Building the Windows installer additionally needs WiX.

Build

./gradlew jpackage

On distributions without deb or rpm tooling, such as Arch, skip the installers:

./gradlew jpackage -PskipInstallers=true

Running from source

From the project directory, with Java 25 or higher installed:

./sparrow

The convenience script in the source tree kept its upstream name, so it is ./sparrow even here. The launcher inside a built or installed package is shrike.

Command line options:

--dir, -d        Path to the home folder
--help, -h       Show usage
--level, -l      Log level: ERROR, WARN, INFO, DEBUG, TRACE
--network, -n    mainnet, testnet, testnet4, regtest or signet

Note that testnet means testnet3.

Home folder

Unless -d says otherwise, Shrike keeps its config, log and wallets in ~/.shrike on macOS and Linux, with the other networks in subfolders. It is a separate location from Sparrow's, so the two installations never share state. On macOS and Linux the XDG base directory specification is supported as an opt-in, resolved per category: where the corresponding directory already exists it is used, otherwise the home folder is. Passing -d disables XDG resolution entirely and puts everything in the folder you name.

Reproducible builds

The release binaries are reproducible, before codesigning and installer packaging. The procedure is kept with the code, in docs/reproducible.md, along with the two regtest walkthroughs that verify the proof of work and the signature hash against a live forked node.