dcrd: the Decred daemon that validates every block and holds no wallet

A daemon that keeps the whole ledger and no keys

dcrd is written in Go and is the full node implementation for the Decred cryptocurrency. The project's own description calls it a fully-validating chain daemon that maintains the entire past transactional ledger and allows relaying of transactions to other Decred nodes around the world. That is the whole job, and the project is unusually explicit about the boundary.

The project states plainly that dcrd does not include wallet functionality. Users who want a wallet need dcrwallet, the CLI wallet daemon, or Decrediton, the GUI bundle. The other pieces in the family are dcrctl, a command line client for both dcrd and dcrwallet, and a CLI app suite that bundles the two daemons.

That separation has a practical consequence. A dcrd install on its own does not sign anything and does not hold spending keys. It validates, stores and relays. If your goal is to receive funds you still need a wallet, and if your goal is to check the chain independently of any third party, dcrd alone already does that job.

For context on why the project exists, the project's overview describes Decred as a blockchain-based cryptocurrency built around community input and open governance, using a hybrid proof-of-work and proof-of-stake mining system so that no small group can dominate transaction flow or change the protocol without community input.

What full validation actually costs the node

A full node is defined as software that validates all transactions and blocks rather than trusting a third party. Nearly all full nodes also relay transactions and blocks to other full nodes, and that relay is what forms the peer-to-peer network the currency depends on.

The project then contrasts this with lightweight nodes, which rely on full nodes to serve the transactions, blocks and cryptographic proofs they need, while still relaying their own transactions outward. The consequence stated for a network with too few full nodes is that lightweight clients might be unable to be served promptly, pushing users toward centralized services, which the project describes as reducing privacy and being vulnerable to censorship.

So the argument for running dcrd is a network argument rather than a personal one. A node contributes security, adds relay paths, and keeps capacity available for SPV wallets. The project also points out an individual angle: because dcrd validates every block and transaction itself, it provides the strongest privacy and security position when paired with a wallet that connects to it directly in full validation mode.

That is a different goal from running a node for convenience. Nobody needs a full node to check a balance. They need one to avoid trusting someone else's answer.

Disk, memory and bandwidth figures you should plan around

The minimum recommended specifications are stated as dcrd only, which signals that they do not cover a wallet. As of January 2026 the figures are 30 GB of disk space, made up of 16.5 GB of blockchain data and 5.5 GB of metadata, and 2 GB of memory. The disk figure grows over time at roughly 2.5 GB per year.

Network traffic is the line most operators underrate. The stated figures include about 150 MB per day of download and about 1.5 GB per day of upload, on top of a one-time download of the entire blockchain. Upload exceeding download by an order of magnitude is the signature of a relay node, and it is the direct cost of contributing to the network the project wants people to run.

Supported platforms are Windows 10, with the server edition preferred, plus macOS and Linux. High uptime is listed as a requirement in its own right, not a nicety, because a node that is offline is a node that is not relaying.

One more operational detail is easy to miss: the firewall must be configured to allow inbound connections to port 9108. A node that only makes outbound connections can validate and follow the chain, but it contributes less of the relay capacity the project is asking for.

Building from source on Go 1.26 or 1.27

The fastest route is a binary rather than a compile. Installation guidance points to the downloads page, and describes Decrediton as the easiest method because it bundles dcrd, with the CLI app suite as the choice for users who prefer the command line. Separate documentation covers how to verify binaries before installing, how to install the CLI suite, and how to install Decrediton.

For a source build, two dependencies are needed. The first is Go, and the build instructions ask for Go 1.26 or 1.27. Checking what you actually have is a two-line exercise:

  $ go version
  $ go env GOROOT GOPATH

You are warned that GOROOT and GOPATH must not sit on the same path. Since Go 1.8 they are set automatically, but you still need $GOPATH/bin on your PATH to run anything installed with go install or go get. On Unix the suggested .profile lines are:

  PATH="$PATH:/usr/local/go/bin"  # main Go binaries ($GOROOT/bin)
  PATH="$PATH:$HOME/go/bin"       # installed Go projects ($GOPATH/bin)

The second dependency is Git, verified with git version. Note that the go.mod file in the repository declares go 1.25.0 as its module directive, which is lower than the Go versions named for the toolchain, so the module file is not the constraint you should size your installation against.

Cloning, installing and checking the dcrd version

The Windows example is a four-step sequence that shows the shape of the whole build:

  PS> git clone https://github.com/decred/dcrd $env:USERPROFILE\src\dcrd
  PS> cd $env:USERPROFILE\src\dcrd
  PS> go install . .\cmd\...
  PS> dcrd -V

The go install call is worth reading closely. It installs the root package and every command under cmd, so the daemon and its command line helpers land together in the bin directory of your GOPATH, which the repository write-up names as $(go env GOPATH)\bin. The final dcrd -V is the check that the binary you just installed actually runs.

The Unix example follows the same pattern with one extra clone, pulling dcrctl alongside dcrd and then running go install across the tree.

Two gaps are worth noting for anyone scripting this. The excerpt does not show how to start the daemon or what its configuration file looks like in the excerpt available here, and the sampleconfig/ directory in the repository layout is where such defaults would live. The top level also holds a Dockerfile and container/ directory, plus a config.go and a sampleconfig directory, so container and file based configuration are both plausible routes even though the available text stays silent on their use.

A monorepo split into independently versioned Go modules

The go.mod file shows something unusual for a daemon repository. The root module is github.com/decred/dcrd, but most of its dependencies are other Decred modules pinned at their own major versions:

module github.com/decred/dcrd
go 1.25.0

Among the required modules are blockchain/v5, blockchain/standalone/v2, blockchain/stake/v5, database/v3, chaincfg/v3, dcrec/secp256k1/v4, gcs/v4, peer/v4, rpc/jsonrpc/types/v5, txscript/v4, wire and dcrutil/v4. Two versions of rpcclient appear side by side, v8 and v9, which tells you the client library is changing shape alongside the daemon and that both are still referenced by the tree.

The version numbers are the point. Each subsystem carries its own major version and can therefore move independently without a flag day for the whole daemon. The same pattern shows up in the directory layout: addrmgr/, bech32/, blockchain/, chaincfg/, crypto/, database/, gcs/, mixing/, peer/, rpc/, rpcclient/, txscript/ and wire/ are all separate importable packages.

That structure is why dcrd can be a library as well as a program. There is a rpcclient package and an rpc/ directory, so other Go programs can talk to a running node instead of shelling out to dcrctl. If you are building tooling around Decred rather than just running a node, this modular layout is the part to study.

Editorial conclusion

dcrd fits operators who want to validate the Decred chain themselves, serve lightweight clients, or give a wallet direct full validation mode connection, and who can spare the disk and uptime the ledger demands. It does not fit someone expecting a standalone wallet, because the daemon explicitly excludes wallet functionality. Before deploying, check the stated disk and bandwidth figures, open inbound port 9108, and decide between the Decrediton bundle, the CLI app suite, or a source build on Go 1.26 or 1.27.

Frequently asked questions

Official sources

1. decred/dcrd on GitHub
2. License: ISC
3. Project website
4. README
5. Releases