DarkFi: a Layer 1 chain where the contracts carry the zero-knowledge proofs

A Layer 1 built around private primitives

DarkFi describes itself as a new Layer 1 blockchain designed with anonymity at the forefront, and the stated goal is to proliferate anonymous digital markets by means of strong cryptography and peer-to-peer networks. The project framing in the repository is blunt, in the description and the title of the code, Anonymous, Uncensored, Sovereign, and the manifesto page it links to puts the political framing in writing.

The technical summary is more useful for an engineer. DarkFi offers flexible private primitives that can be wielded to create any kind of application, and it uses advances in zero-knowledge cryptography together with a contracting language and developer toolkits to create uncensorable code. The aim stated in the README is to make anonymous engineering highly accessible to developers, which is the part of the claim that a repository can be checked against, because a contracting language, a proof assembler and SDKs are all things that exist or do not.

The running network is described as the DarkFi Alpha Testnet, a proof-of-work blockchain that provides fully anonymous transactions, zero-knowledge contracts, anonymous atomic swaps, a self-governing anonymous DAO, and more. An alpha testnet means exactly what it says: the cryptography and the machinery are the point, and the network is where they are exercised.

The project is written in Rust and carries the AGPL licence, and it is hosted on its own git service at `git.dark.fi` rather than only on GitHub, with the Cargo metadata naming the Dyne.org foundation as the author.

darkfid, drk and xmrig split the node, the wallet and the miner

Three binaries cover the operational roles, and the division is easy to hold in the head.

`darkfid` is the DarkFi full node. It validates blockchain transactions and stays connected to the peer-to-peer network. `drk` is the command line wallet, and it does the things a wallet is expected to do: it provides an interface to smart contracts such as Money and DAO, manages keys and coins, and scans the blockchain to update balances. `xmrig` is the mining daemon, it connects to `darkfid` over its Stratum RPC, and it requests new block headers to mine.

The Stratum RPC detail is the one that matters for anyone wiring a node together. Mining is not a separate process that talks to the network directly; it talks to the full node, which means the node is the thing that has to be running, connected and configured before any mining happens.

There is more than these three. The workspace also contains `zkas`, the circuit assembler, an `explorer`, a `vanityaddr` tool, `taud` for the tau auditor, `lilith`, and the `fud` pair. The IRC daemon has its own installation and build instructions in the book, separate from the node, and it is described as the P2P IRC daemon.

The documentation is a book rather than a README, published as an mdbook at `dark.fi/book/`, and the README points at the specific chapters: the testnet node tutorial, the darkirc installation, and an introductory chapter for people who want to work on the source.

Building it: Rust 1.87, a wasm32 target and a long dependency list

The build instructions are complete enough to follow without guessing, which is not always true of a project with this many moving parts.

Start by taking the source and entering the directory:

% git clone https://git.dark.fi/darkrenaissance/darkfi
% cd darkfi

The project requires the Rust compiler, and the README points at Rustup for the installation instructions. Two toolchain details follow: a native toolchain has to be set up during the Rust installation, and the wasm32 target has to be added, because parts of the system are compiled to WebAssembly:

% rustup target add wasm32-unknown-unknown

The minimum supported Rust version is 1.87.0, and there is a `rust-toolchain.toml` in the repository root.

Then come the native dependencies, and there are more of them than a Rust project usually needs: git, cmake, make, gcc, g++, pkg-config, alsa-lib, clang, fontconfig, lzma, openssl, sqlcipher and sqlite3. On a Debian-based system the README gives the whole set as one command:

# apt-get update
# apt-get install -y git cmake make gcc g++ pkg-config libasound2-dev libclang-dev libfontconfig1-dev liblzma-dev libssl-dev libsqlcipher-dev libsqlite3-dev

The presence of alsa-lib, fontconfig and sqlcipher tells you the node is not a headless daemon with no dependencies; it has audio, font and encrypted database requirements, which is a strong hint about what a user interface built on it does.

There is a shortcut, and the README recommends it for the impatient:

% sh contrib/dependency_setup.sh

The script tries to recognise the system it is running on and install the dependencies accordingly, and the README asks that people add support for their package manager and send a patch if it is not recognised.

Finally, the binaries are built with the Makefile:

% make

Installation is optional and separate, and it does something a plain `make install` often does not:

# make install

The binaries go to `/usr/local` by default, the configuration files are bundled with the binaries and contain sane defaults, and you have to run each daemon once for it to spawn a configuration file that you can then review. A node that has never been started has no configuration, so this step is the moment where an operator reads the defaults before they become production settings.

The Makefile compiles zero-knowledge circuits into .bin artifacts

The Makefile is where the interesting build step is, and it is not a thin wrapper around cargo.

BINS = \
	zkas \
	darkfid \
	drk \
	darkirc \
	lilith \
	taud \
	vanityaddr \
	explorer \
	fud \
	fu

Those are the binaries the build produces, and the default target depends on two things: the compiled circuits and the binaries themselves.

The circuits come from the `proof/` directory and from `src/event_graph/proof/`, and every `.zk` file in those places is picked up by a `find` and compiled with `zkas` into a `.bin` artifact. The `zkas` crate is the assembler, and it is a workspace member of its own, so the proof toolchain is built from the same source tree as everything else rather than being an external dependency.

The dependency graph is written out in the rules. `darkfid` and `drk` both depend on the `contracts` target, which in turn builds the three contracts in `src/contract/money`, `src/contract/dao` and `src/contract/deployooor`. `darkirc` and `taud` depend on the compiled circuits. So a change to a contract forces a rebuild of the node and the wallet, which is the correct dependency, and it also means a full build is a long one.

The Makefile also has the usual knobs for a project that has to be cross compiled: `PREFIX` defaults to `$(HOME)/.cargo`, `RUST_TARGET` is derived from the host triple, and the comments show the `RUSTFLAGS` lines for musl static builds and for a native `target-cpu` tuned build.

A workspace of contracts, an SDK, a serial format and a Tor client

The `Cargo.toml` is the map of the codebase.

[package]
name = "darkfi"
version = "0.5.0"
homepage = "https://dark.fi"
description = "Anonymous. Uncensored. Sovereign."
authors = ["Dyne.org foundation <[email protected]>"]
repository = "https://git.dark.fi/darkrenaissance/darkfi"
license = "AGPL-3.0-only"
edition = "2021"

The version is 0.5.0, the licence is AGPL-3.0-only, and the edition is 2021.

The workspace members describe the layers. The binaries sit in `bin/`, one crate per program. Under `src/` there is an `sdk` with a `python` SDK beside it, a `serial` crate with two derive crates under it, and a `contract` directory holding the test harness and the three contracts, money, dao and deployooor. An `example/dchat/dchatd` shows what a contract application looks like in practice.

The serial crates are worth a note, because a blockchain needs a canonical way to encode a transaction, and the fact that the encoding and its derive macros are a first-class crate rather than an afterthought says the format is meant to be used by other implementations too.

The dependency list shows the networking choices. There is `futures-rustls` for TLS, `socket2` for pluggable transports, and then the Tor stack: `arti-client` at 0.42 with features that include `onion-service-client` and `onion-service-service`, plus `tor-error`, `tor-rtcompat` and `tor-hscrypto`. The runtime choices are the same idea, with `async-std`, `smol` and `futures` all optional behind `async-trait`.

The repository root also carries `proof/` for the circuits, `example/` with sample `.zk` files, `fuzz/`, `bench/`, `script/`, `contrib/`, `doc/` and `tests/`, and a set of files that say something about how the project is worked on: `AGENTS.md`, `opencode.json`, an `.opencode/` directory, an `openspec/` directory and `IDEOLOGY.md`.

Where DarkFi is the wrong tool

Three limits are visible in the repository itself, and they are worth weighing before anyone starts a build.

First, the network is an alpha testnet with a proof-of-work chain, and the newest tagged artifacts are app releases: `app-0.3-alpha` from 2025-11-01, `app-0.2.4-alpha` from 2025-06-27 and `app-0.2-alpha` from 2025-05-06. There is no release in the list that looks like a mainnet, and the code version in `Cargo.toml` is 0.5.0, so nothing here claims production readiness.

Second, the operational weight is real. The native dependency list includes alsa-lib, fontconfig, sqlcipher, sqlite3, clang, lzma and openssl, the minimum Rust version is 1.87.0, and the build compiles every `.zk` circuit in the tree before it compiles the binaries. This is not a library you add to a service; it is a system you run.

Third, the licence is AGPL-3.0-only. For a project that offers a service over a network to third parties, the AGPL is the licence designed to reach exactly that case, so a commercial deployment on this code needs its own review rather than an assumption that the permissive licences of its dependencies carry over.

There is also a detail in the build that is easy to miss and easy to regret: the configuration file is generated when a daemon first runs, and the README says you have to run each daemon once in order for it to spawn a config file, which you can then review. A node that has been started with unreviewed defaults and then left running is a node nobody knows the configuration of.

The alternative approach depends on what you are trying to build. If the goal is a private application on top of an existing network, the alternative is to write the privacy layer as a contract or a service against a chain that already has users, and to keep the zero-knowledge work to the circuit and the proof, which is a much smaller problem than running a chain. If the goal is a new chain, the alternative to DarkFi's contracting language and `zkas` assembler is to build the circuits and the contract execution on top of an existing proving stack, which trades the integrated toolchain and the anonymity primitives for a smaller surface area and a familiar ecosystem. The repository's own examples, `example/simple.zk`, `example/array.zk` and `example/zk.rs`, are the cheapest way to see how much of the second approach DarkFi already gives you.

Editorial conclusion

DarkFi fits a developer who wants to write privacy primitives rather than bolt privacy onto someone else's chain, who is comfortable in Rust, and who can accept an AGPL codebase and a network that is still an alpha testnet. It is the wrong choice for an application that needs a working mainnet today, because the documented network is the alpha testnet and the newest tagged artifact is an alpha app release from 2025-11-01, and it is the wrong choice for a team without the systems background to run a proof-of-work node and review the configuration it generates. Before building it, install the native dependencies exactly as the README lists them, since sqlcipher, sqlite3, alsa and clang are not optional for the build, and read the contract examples under `example/`, which are the shortest path to understanding what the contracting language can express.

Frequently asked questions

Official sources

1. darkrenaissance/darkfi on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases