kaspad: the deprecated Go full node for the Kaspa network

The repository says deprecated in its own first line

The README opens with a single word, DEPRECATED, and then explains why. The full node reference implementation was rewritten in Rust, and as a result the Go implementation is now deprecated. There is a second paragraph that is more pointed. Any pull requests or issues opened in this repository will be closed without treatment, except for issues or pull requests related to the kaspawallet, which remains maintained. In any other case, the README directs you to the Rust implementation instead. That last exception is the only live part of this codebase in practice, and the practical consequence for anyone evaluating this repository today is that adopting it means adopting a wallet component of a node implementation that no longer exists in this language. The last push was on 2026-06-05, the most recent tagged release is v0.12.23 from the same date, and the previous one, v0.12.22, dates from 2025-05-08, so the repository is not frozen, it is finishing its business.

What Kaspa is, and why the node matters

The README explains the underlying chain. Kaspa is an attempt at a proof-of-work cryptocurrency with instant confirmations and sub-second block times, and it is based on the PHANTOM protocol, described as a generalization of Nakamoto consensus. The significance of that generalization is what makes a full node implementation worth caring about in the first place. The direction of a block has more than one possible parent in a PHANTOM-style design, so a node has to track a DAG rather than a single chain, and the ordering of transactions becomes a separate problem from their inclusion. Kaspad was the reference full node for that network, written in Go, which is a reasonable choice for a node: a garbage-collected language with good concurrency primitives, a static binary, and a standard library that covers the networking and database work a node needs.

Building it takes Go 1.23 and three commands

The requirements section names Go 1.23 or later, and the go.mod agrees, declaring the module as github.com/kaspanet/kaspad with go 1.23. The installation instructions start with installing Go and confirming the version:

$ go version

Then the clone and install:

$ git clone https://github.com/kaspanet/kaspad
$ cd kaspad
$ go install . ./cmd/...

The `go install . ./cmd/...` form matters. The first path installs the root package, which is the node itself, and `./cmd/...` covers the utilities that live under the `cmd/` directory. The README notes that kaspad and the utilities should then be installed in `$(go env GOPATH)/bin`, and that if you did not already add the bin directory to your system path during Go installation, you are encouraged to do so now. That last sentence is the one that catches people: the binary builds fine and then appears to be missing because `go install` puts it somewhere the shell does not look.

Running it needs no configuration at all

The Getting Started section is unusually short for a node implementation. Kaspad has several configuration options available to tweak how it runs, but all of the basic operations work with zero configuration:

$ kaspad

That claim is about the basic operations only, and it is worth reading it that way. The repository layout shows how much machinery sits behind that single command. There is an `app/` directory for the application layer, `domain/` for the protocol rules, `infrastructure/` for the database and networking, `cmd/` for the command line utilities, `util/` for shared helpers, `testing/` and `stability-tests/` for the test suites, a `docker/` directory, and `version/` for version metadata. The layering is the conventional one for a blockchain node: the protocol logic is kept separate from the persistence and the peer-to-peer layer so that the consensus rules can be tested without a network. The dependency list in go.mod matches that shape, with a LevelDB binding for the chain database, a secp256k1 implementation for the cryptography, a BIP39 package for key derivation, gRPC for the RPC surface, and a directory lock library so that two node instances do not share one data directory.

The dependency list is short, and the tooling is conventional

The go.mod requires a little over twenty modules, most of them long-established: btcutil, go-socks, winsvc for Windows service support, go-spew for test output, flock for the directory lock, protobuf and gRPC for the RPC layer, jessevdk/go-flags for command line parsing, jrick/logrotate for log file rotation, and the crypto packages go-muhash, go-secp256k1, golang.org/x/crypto, plus go-bip39 for mnemonics and x/term for terminal handling. The indirect set is small. That is a reasonable sign for a node, because a consensus implementation's dependency surface is attack surface, and a project that reached for many outside packages would be carrying more third-party code into the path where a consensus bug matters most. The `docker/` directory and a `.dockerignore` are also present, and the repository has a `build_and_test.sh` script plus a `changelog.txt`, which is how a project keeps a running record of the fixes applied to a released node.

Where kaspad is the wrong tool, which is most of the time

The honest answer is that kaspad is the wrong tool for anyone starting a new node deployment, because the project says so itself. The Rust rewrite, rusty-kaspa, is where new work belongs, and the README says so without hedging. Beyond that, there is a second consideration for anyone tempted to run this code anyway, for example to study a Go implementation of a DAG-based consensus or to pin an exact node version for historical research. The reason to be careful is the ISC licence combined with the deprecation. The code is permissively licensed and you can read it, fork it and run it, but you are running a node implementation whose own authors have told you not to. A node that syncs and validates a chain is exactly the kind of software where you want the version that the network's operators are actually running, because a divergence in consensus handling between your node and theirs shows up as a node that stalls or rejects blocks rather than as an error message. The kaspawallet exception is narrower still, since the README only promises maintenance for issues and pull requests related to it, not for the node.

The alternative is rusty-kaspa, and the difference is the language and the maintenance

The realistic alternative is the Rust implementation, and the difference in approach is not subtle. Both implement the same protocol, so the network behaviour is the same. What changes is the runtime and the lifecycle. Rust gives the rewrite the same properties the Go version had, a static binary with no garbage collector pauses and predictable memory behaviour, which matters for a node whose job is to validate and relay blocks against a wall clock. The difference in maintenance is the part that actually decides it. This repository's own policy is that anything not about the kaspawallet will be closed without treatment, so the cost of running the Go code is not that it breaks but that when it does, nobody is fixing it and you are on your own with a consensus implementation. The Go code still has value as a readable reference, since a second implementation of the same protocol in a different language is genuinely useful for anyone trying to understand how PHANTOM ordering and the DAG are handled, and for that purpose reading the code beats running it.

Editorial conclusion

kaspad fits a developer who wants to read a complete full node implementation of a DAG-based consensus in Go, and nothing else. It is the wrong choice for running a Kaspa node, since the repository states the Go implementation is deprecated and closes issues for anything but the kaspawallet, and the Rust implementation at kaspanet/rusty-kaspa is where node work belongs. Before you rely on this code, check that rusty-kaspa has what you need, and if you do pin the Go version deliberately, note that it requires Go 1.23 or later and that the tagged release line ends at v0.12.23 from 2026-06-05.

Frequently asked questions

Official sources

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