firo: a privacy cryptocurrency built on the Spark protocol

The cryptographic claims, as the project states them

Firo is described as a privacy-focused cryptocurrency that uses the Spark protocol, and the readme is specific about what that buys you: high anonymity sets without requiring a trusted setup, and relying on standard cryptographic assumptions.

That combination is the core of the design. A setup ceremony is a point of failure and a coordination burden, and a proof system that needs none of it is easier to reason about. Depending on standard assumptions rather than something bespoke is the other half of the appeal, since it means the security argument is one a reader can check against the literature.

Address hiding is handled separately, with Dandelion++, which obscures the originating IP address of transactions without relying on any external service such as Tor or i2P. That is worth noting as a design choice rather than a feature: no dependency on a second network to reach the network.

The consensus side is a hybrid proof of work and LLMQ chainlocks system, described as combining fair distribution of supply with protection against majority attacks and quick finality of blocks and transactions. The proof of work itself is FiroPOW, a variant of ProgPOW, which targets graphics processors and is resistant to field programmable gate arrays and application specific chips. The topics list carries the ancestry: Sigma and Zerocoin for the zero knowledge lineage, Lelantus, and merkle tree proof of work.

The project is MIT licensed per the package metadata, the code is C++, and the release cadence in the listed versions is steady, with three releases of the same patch line between August and October 2026, and the last push on 2026-10-22.

Docker is the easy path, and the GUI is the casualty

The readme says that if you are already familiar with Docker, running Firo that way might be the easier method, and then it gives a caveat that shapes the whole experience: the graphical interface is not supported when running with Docker, so you can only use the remote procedure call interface, over HTTP or through the command line utility, to interact with Firo.

There are two ways to get a container.

The first is to build the image yourself from the Dockerfile in the repository, which the readme calls the local Dockerfile:

docker build . -t firo-local

and then to run a container from that image, mapping the data directory from your home directory into the container:

docker run -d --name firod -v "${HOME}/.firo:/home/firod/.firo" firo-local

The second is the published image on Docker Hub, which the readme tells you to pull and run the same way, and which is the version most people should use.

There is a wrinkle the readme is honest about. If the data folder does not already exist, you should create it yourself, and it describes this as a workaround until a particular issue is resolved. The container expects a directory it cannot create for itself in the mapped path, which is a small thing that would otherwise stop a first run with a permission error.

The image itself is built carefully, on a Debian base, and the last stage runs as a dedicated unprivileged user with the data directory as a volume, so the wallet is not owned by root inside the container.

Driving a node from the command line

The container section then lists the commands you will actually use, and they are worth reproducing because the first one has a warning attached.

To see the current block count, which the readme says might take a while since the daemon needs to find other nodes and download blocks first:

docker exec firod firo-cli getblockcount

To see the connected nodes:

docker exec firod firo-cli getpeerinfo

And then the lifecycle commands, stopping the daemon and starting it again, and one that is worth internalising before you need it:

docker cp firod:/home/firod/.firo/wallet.dat .

That last one is a backup of the wallet file out of the container and onto your host. It appears in the documentation between the stop and start commands, which is a good place for it, because a wallet file inside a container volume is exactly the thing you lose if the volume is removed by mistake.

Everything is done through the daemon and the command line utility, which is the practical consequence of the missing graphical interface. For a node operator that is a reasonable trade, since the graphical wallet is a client rather than the node itself, but it does mean the container route is a server route.

Building from source means building a dependency tree first

The Linux build section explains a structure that is unusual outside of the older cryptocurrency codebases and is worth understanding before you start.

Firo contains build scripts for its dependencies, so that the versions of all the component pieces are known to be compatible. There is a directory of depends instructions with extra options such as cross compilation, and a separate document with the full Unix build instructions if you would rather assemble the dependencies yourself. Bootstrappable builds, in the strongest sense of the word, can be achieved with Guix, and the readme points at a directory explaining how.

After that come the development dependencies, listed per distribution family, and the lists are long because the graphical wallet needs a separate toolchain. On Debian, Ubuntu and Mint, with a minimum of Ubuntu 18.04, the base list is a compiler, build tools, CMake and a caching compiler, and the graphical wallet adds Qt tools, a keyboard library, bison, ninja, meson and the X11 headers. On Red Hat and Fedora the list is similar, and it includes a small piece of advice that is easy to miss: linking the bison binary to yacc. On Arch the list is short, which is a reminder of how distribution packaging can carry a lot of the burden.

The build itself is then three steps. Clone the repository, build the dependencies in the depends directory with a parallel make, and configure with CMake.

The CMake options are the real configuration surface

The build produces a small set of binaries, and the CMake options table tells you which ones you can turn off. The readme says that if the build succeeded, the binaries will be in the build directory: the daemon, the command line utility, and the graphical client if the interface is enabled.

The options table is the reference to keep. The daemon build flag is on by default, and so is the graphical client and the command line build, and the wallet functionality is enabled by default. The test suite is off by default, and the transaction tool build is a subset of the command line build, which is the kind of default that only makes sense if the transaction tool is a strict part of the command line tools rather than an extra.

The two configurations you will actually use are the headless one and the full one. The headless configure disables the graphical interface and enables the command line tools, which is the right choice for a server. The full one enables both. The test configuration adds the test suite and disables the interface, and the readme recommends building and running the tests, with the test invocation afterwards.

The dependency build has the same switch, in the form of an environment variable that turns the interface off while building the dependencies, and the Dockerfile uses it for exactly the same reason, so that the container has no graphical dependency to satisfy.

What to check before you run a node

A short list of things to settle, in the order they will bite.

The build is heavy. There is a dependency tree to build with its own compiler requirements, a graphical toolchain if you want the wallet, and a CMake configure that needs a generated toolchain file. The Docker route avoids all of it, at the cost of the interface, so for a first node the container is the obvious choice.

The licence is MIT, and the tree carries a COPYING file, which is the document to read.

The wallet needs a backup plan, and the readme hands you the command, because a wallet file in a container volume is one volume removal away from gone. Copy it out before you experiment.

The sync needs patience. The block count command is documented as potentially slow while the daemon finds peers and downloads blocks, so a node that looks stuck in the first minutes is behaving as documented.

And the project metadata tells you what kind of repository this is. There is a Jenkinsfile for continuous integration, the usual GitHub workflows, an AGENTS file and a Claude file for automated tooling, a transaction configuration directory, a quality assurance directory, and a document file describing the network node. The releases are in the zero fourteen line with three point releases in two months, so the code is being maintained on a steady cadence rather than left alone.

What the readme does not give you is a threat model or an audit, and for a privacy currency that is a gap a reader should close elsewhere.

Editorial conclusion

Adopt Firo if you are evaluating privacy coins with a proof system that avoids a trusted setup and address hiding that does not depend on an overlay network, and you are prepared to run a node that takes a long time to sync. Do not adopt it if you need a light wallet or a quick install, because the node is the product, the first block count query can take a long while, and the build pulls a large dependency tree. Before you commit funds or run a node, read the COPYING file, since the licence is MIT, and back up the wallet file out of the container before you touch the volume, because the documentation shows exactly that command and for a good reason.

Frequently asked questions

Official sources

1. firoorg/firo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases