Firedancer: building and starting the Solana validator client

Why Firedancer adds a second Solana validator path

Firedancer addresses a narrow but consequential problem in Solana infrastructure: operating a validator client whose implementation is separate from Agave. The repository is primarily written in C and positions its networking, concurrency, and validator components around low-latency systems techniques. Its separate implementation gives network operators client diversity, which the README says helps reduce exposure to supply-chain attacks affecting build tooling or dependencies.

This is validator software, not an RPC endpoint, wallet, transaction simulation service, or application SDK. The intended reader is an operator who already understands Solana participation or wants to evaluate it, or a systems developer who wants to build the binaries and work with their configuration. The documentation links operators to the external Getting Started guide, but the repository README gives only a development-scale entry path. It does not present Firedancer as a replacement for every part of an existing Solana deployment.

Two validators come from this codebase. Firedancer is the complete client written from scratch, with no Agave code. Frankendancer is a hybrid validator that uses Firedancer networking and block-production components while retaining Agave code for execution and consensus. That distinction matters when comparing claims about implementation independence: the two artifacts do not have the same dependency boundary.

The validator data path and hybrid architecture

The repository describes performance and isolation goals, but it does not provide a full packet-level account of validator processing in the README. What can be established is the division between the two validators. Frankendancer uses the Firedancer networking stack and block-production components when acting as leader, then delegates execution and consensus to Agave validator code. The full Firedancer validator has no Agave code.

The architecture is intended to support a highly restrictive sandbox and very few system calls. That is a design property, not a documented guarantee about every build or deployment. Operators should distinguish the stated security architecture from an independently verified operating configuration. The README also does not specify consensus messages, account-store layout, scheduler behavior, snapshot handling, or the exact networking sequence, so those mechanisms should be treated as undocumented in the available project text.

The build itself is organized through `Makefile` and machine descriptions under `config/machine/`. `MACHINE` selects a target description, while `EXTRAS` can enable optional feature files such as `with-debug.mk`. The default `make -j` builds the native validator binaries. The broader `make -j all` target also builds libraries, headers, unit tests, and fuzz tests, giving developers a clear route beyond the two production executables.

Building Firedancer on Linux and launching testnet

The documented development path assumes Linux and a kernel of at least version 4.18 to build. Clone the repository, install dependencies, compile in parallel, and launch the development validator with the documented testnet flag:

git clone https://github.com/firedancer-io/firedancer.git
cd firedancer
./deps.sh
make -j
./build/firedancer-dev --testnet

`deps.sh` installs system dependencies. `make -j` builds `firedancer-dev` and the native Firedancer binary, as described in the README and `Makefile`. The final command starts `firedancer-dev` in testnet mode. The README does not document expected terminal output for that command, so the useful confirmation is the process and configuration state produced on the local host rather than an invented success message.

Running `firedancer-dev` without arguments is a different first use. It configures the machine for validator operation and creates a local development cluster, including a genesis block, keys, and a faucet. It then starts a validator on that machine. This path may invoke `sudo` for privileged system changes. Without usable `sudo`, the README says the command may have to run as root, which is a material operational boundary rather than a minor convenience issue.

To add another validator to the local cluster, set `[gossip.entrypoints]` in the configuration file to the first validator and start the joining process with `firedancer-dev run`. The README does not show the complete configuration file or the exact host and port syntax, so those details must come from the documentation and generated configuration.

Build controls that matter for native C development

The `Makefile` supports separate build trees for different machine targets. A target-specific invocation sets `MACHINE` and selects a description from `config/machine/<name>.mk`:

MACHINE=my_machine make help

That command prints targets associated with the selected machine, including cleaning, dependency generation, preprocessor output, and assembly output. The README and Makefile do not include a ready-made `my_machine` configuration, so this example illustrates the documented variable and target convention, not a ready-to-copy machine profile.

Optional features use `EXTRAS`. The Makefile identifies `debug` as an example that loads `with-debug.mk`:

make -j EXTRAS="debug"

This can be useful for development, but the available text does not describe the runtime behavior of the debug feature. Developers should inspect the corresponding file under `config/extra/` before assuming that a debug build is appropriate for validator deployment.

There is also a build-host caveat around CPU isolation. If the kernel uses `isolcpus`, the Makefile says a normal parallel build will generally use non-isolated CPUs even if more cores are requested with `-j[N]`. It points contributors to the `make-j` script in `contrib` for build advice. This affects build planning rather than validator operation, but it can matter on servers configured for latency-sensitive workloads.

Frankendancer versus Agave and the full validator

Agave is the most relevant comparison because the repository defines Frankendancer partly through it. Agave provides the execution and consensus code used by the hybrid validator. Frankendancer substitutes Firedancer networking and block-production pieces and is described as improving performance while leader. That is a narrower architectural change than replacing Agave throughout the validator.

The full Firedancer client removes Agave code entirely. Its benefit is implementation separation from the established client, but the README does not claim that every operational workflow, feature, or compatibility condition is identical. In particular, it does not provide a feature matrix comparing full Firedancer with Frankendancer or Agave. A team should not infer parity merely because both validators originate in this repository.

For an operator already running Agave, Frankendancer may be the more conservative comparison because its execution and consensus implementation remains Agave. For a network operator prioritizing an entirely independent client, the full validator is the relevant artifact. Neither choice is documented here as a drop-in replacement, and the repository does not state migration procedures, key compatibility details, or rollback behavior.

Linux, privileges, dependencies, and release constraints

The clearest limitation is platform scope. The README says Firedancer currently supports only Linux and requires a relatively new kernel, at least version 4.18, to build. This excludes ordinary macOS and Windows workflows. Native compilation also means that system headers, compilers, libraries, and kernel capabilities become part of the operator's setup burden.

`./deps.sh` modifies the host's dependency state. The available text does not enumerate every package installed by that script or describe an isolated container workflow, so operators should read the script before applying it on a production machine. Validator launch may also make privileged changes through `sudo`. Root execution is documented as a possible fallback, not merely as an installation recommendation.

The repository records a last push on 2026-10-16, and recent release entries include `v26.10.2`, titled Firedancer Mainnet Release, dated 2026-10-14, plus testnet releases dated 2026-10-09 and 2026-10-07. These facts show recent release activity, but the README does not document an upgrade policy, supported-release window, migration sequence, or compatibility matrix. A production operator must obtain those details from the Releases Guide before replacing a validator binary.

The README identifies Apache 2 licensing for Firedancer and says external libraries carry various licenses. GitHub classifies the repository license as custom, so the decisive source for review is the repository's `LICENSE` and `NOTICE` files rather than the repository metadata label. The README does not offer legal interpretation, so license compatibility should be checked for the exact build, dependencies, and distribution model.

Editorial conclusion

Firedancer suits Linux operators evaluating a second Solana validator implementation, especially those prepared to manage a native C build and privileged system configuration. It does not suit macOS or Windows users, developers seeking a lightweight SDK, or teams that cannot review the custom dependency and licensing boundaries. Before adoption, verify kernel support, inspect `LICENSE`, `NOTICE`, and `deps.sh`, and compare the operational requirements of Firedancer with Agave for the intended validator role.

Frequently asked questions

Official sources

1. firedancer-io/firedancer on GitHub
2. Issues
3. Project website
4. README
5. Releases