rusty-kaspa: the Kaspa node written in Rust

A replacement for the Go node, not a second network

The positioning in the readme is precise and it is the first thing to understand. The project is the Rust based implementation of the Kaspa full node and its ancillary libraries, and the node release serves as a drop-in replacement to the established Go node, which is described as the recommended node software for the network. So the goal is not a fork with different consensus rules, it is the same network with a different implementation of the same rules, and the bar that implies is a full node, not a library. The invitation at the top of the readme is for developers and blockchain enthusiasts to collaborate, test and optimize the implementation, and the framing of each line of code as a contribution to an open source blockchain movement is a reminder that a consensus implementation is reviewed differently from an application. The stated aims are scalability and speed without compromising on security and decentralization, and the point about the project introducing developers to what is possible with Rust in the Kaspa network's context.

A workspace of sixty crates, split by concern

The Cargo manifest lists the members of the workspace, and reading them is the quickest way to understand the scope. There is the node itself under kaspad, a daemon, a command line interface, the consensus implementation split into a core library, a client, a notify component and a proof of work component, and the sequential commit and sparse Merkle tree store parts of consensus as their own crates. The database layer is split across a database crate and a subdirectory for the storage engine, and the crypto directory holds separate crates for hashes, the muhash implementation, addresses, the Merkle tree and the sparse Merkle tree. The RPC surface is the largest cluster, with core, service, gRPC core, client and server, and a WebSocket family with server, client, proxy and WASM variants, plus example programs for a subscriber, a simple client and a version two client. The wallet is split into native, core, WASM and macro crates plus dedicated crates for BIP32, key management and the PSBT format, and there is a separate WASM workspace and a cryptography transaction script directory that includes a zero knowledge SDK. The index directory holds core and processor crates alongside a UTXO index, and the miscellaneous crates cover the address, connection and consensus managers, the bridge, mining, the p2p protocol and its flows, utilities, metrics, system information and build information. The manifest requires a Rust version of 1.95 and uses edition 2024.

The build needs an unusual toolchain on Linux

The Linux instructions are the longest of the three and they explain what this project needs. The general prerequisites are the usual ones:

      sudo apt install curl git build-essential libssl-dev pkg-config

Protobuf is required for the gRPC layer, with a comment saying so explicitly, and the clang toolchain is required for the RocksDB and the WASM secp256k1 builds, which is the part that trips up most people. The Rust toolchain follows, with a note to run the updater if it is already installed, then wasm-pack and the wasm32 target:

      cargo install wasm-pack

      rustup target add wasm32-unknown-unknown

And then the repository itself is cloned:

      git clone https://github.com/kaspanet/rusty-kaspa

The two toolchain requirements are not incidental. The WASM build of the secp256k1 library is how the wallet runs in a browser, and the native build of the same library is what the node links against, and the LLVM and clang packages are needed for both. The build also has a musl toolchain directory in the repository and a Docker build script for multiple architectures, so there is a path to a reproducible container build if the local toolchain fight is not worth having.

The Windows build has a documented LLVM problem

The Windows instructions are the ones worth reading closely, because the documentation states a specific caveat. The steps are to install Git for Windows, then Protocol Buffers and add its bin directory to the path, then a specific LLVM release, after which the bin directory of that LLVM installation is added to the path and the LIBCLANG_PATH environment variable is set to point at the same directory. Then comes an important note about C++ dependency configuration issues, saying that the LLVM archiver installation on Windows may not function correctly when switching between WASM and native C++ compilation, contrasting native RocksDB plus secp256k1 against the WASM32 build of secp256k1, and that manually setting the archiver environment variable also confuses the C++ build toolchain, since it should not be set for native builds but should be set for the WASM32 target. The stated workaround is to go to the LLVM bin directory after installing and copy or rename the archiver executable to the plain name. It is an honest description of a toolchain papercut, and it is the kind of thing that makes a Windows contribution noticeably harder than a Linux one.

The macOS build and the Homebrew LLVM path

On macOS the instructions are shorter because Homebrew covers more. Protobuf is installed with the package manager, and then the note explains why the default Xcode LLVM is not enough, that the default installation does not support WASM build targets, and that for a WASM build on macOS you need the Homebrew version of llvm, with the version given as 16.0.1 at the time of writing. There is a caveat about Homebrew using different installation locations depending on the configuration, and the two possible paths are given, one for an Apple Silicon prefix and one for the Intel prefix, with the advice that a listing of the package tells you which applies. The documentation then shows how to check the actual location and how to adjust the paths accordingly, and finishes with the shell profile change that puts the Homebrew LLVM binaries on the path. The recurring theme across the three platforms is the same, which is that the LLVM version and its location matter, and that the WASM and native builds want different settings from the same installation.

Branches, hardforks and the shape of the release

Two operational details are worth pulling out. The first is the branch policy, which is stated plainly: the default branch is master and new contributions are constantly merged into it, and for a stable branch corresponding to the latest stable release you should pull and compile the stable branch. That is the opposite of the usual convention where master is stable, and it is a detail that will catch out anyone who assumes otherwise. The second is the hardfork history, and the readme records the Crescendo Hardfork, which took place on May 5, 2025 at approximately 15:00 UTC, transitioning the network from a block rate of 1 BPS to 10 BPS and incorporating several major improvement proposals. The release history follows the same pattern, with v2.0.0 and v2.0.1 named as the mainnet Toccata release in June 2026 and v2.1.0 following in September. The workspace version is 2.1.0 and the crate licence field is ISC, while the licence field recorded for the repository itself says it is a custom licence GitHub cannot classify, so the LICENSE file in the repository is the term to read.

Editorial conclusion

rusty-kaspa is a good fit for a developer who wants to work on Kaspa in Rust, particularly if they want to contribute to a consensus-critical node, since the crate layout separates consensus, the database, the p2p protocol and the RPC layers in the way a node project needs. It is the wrong choice if you want to run a node for personal use, since the Go implementation is the established one and this is explicitly positioned as its replacement rather than as a competitor. It is also the wrong choice if you need a WebAssembly build of the whole node, since the WASM support is aimed at the wallet and the secp256k1 and consensus components rather than at a full node, and the Windows build instructions carry a documented problem with the archiver. Before contributing, clone the stable branch rather than master, since master is where new work lands, and note the toolchain requirements, since the build needs a recent Rust release, the LLVM and clang toolchain for the WASM and native secp256k1 builds, and protobuf for the gRPC layer. The licence field on the repository is not identified, while the workspace manifest declares the ISC licence.

Frequently asked questions

Official sources

1. Issues
2. kaspanet/rusty-kaspa on GitHub
3. License: ISC
4. README
5. Releases