# dcrd options

`dcrd` uses rpc credentials, so it's recommended to secure your secrets using a tool like [sops-nix](https://github.com/Mic92/sops-nix).

## sops-nix

Render `dcrd.conf` with `sops-nix` and point the service at it. Example:

```nix
{ config, lib, pkgs, ... }:
{
  # Define credentials as secrets
  sops.secrets."dcrd/rpcuser" = {};
  sops.secrets."dcrd/rpcpass" = {};

  # Render dcrd.conf owned by the dcrd service user/group
  sops.templates."dcrd.conf" = {
    owner = config.services.dcrd.user;
    group = config.services.dcrd.group;
    mode = "0440";
    restartUnits = [ "dcrd.service" ];
    content = ''
      [Application Options]
      # example settings
      rpcuser=${config.sops.placeholder."dcrd/rpcuser"}
      rpcpass=${config.sops.placeholder."dcrd/rpcpass"}
    '';
  };

  # Ensure dcrd only starts when the config exists
  systemd.services.dcrd.unitConfig.ConditionPathExists =
    config.sops.templates."dcrd.conf".path;

  # Point the module to the rendered config
  services.dcrd = {
    enable = true;
    configFile = config.sops.templates."dcrd.conf".path;
  };

}
```

## Notes

Instead of using DynamicUser, the module necessarily runs `dcrd` as a fixed `User`/`Group` and uses a non-private state directory so `rpc.cert` can be read by intended consumers.

- `dcrd` writes `rpc.cert` into its data dir (`--appdata`, defaulting to `/var/lib/dcrd`).
- Consumers (e.g., wallets, tooling) often need to read `rpc.cert` without elevated privileges.
- With `DynamicUser=true`, systemd places state under `/var/lib/private/dcrd` and uses an ephemeral UID, which prevents other users/services from traversing the directory and reading `rpc.cert`.