Build Your Own Blocks: Set Up DMND End to End with StratumV2

A single guide from bare node to mining your own blocks.

Keep an eye on the client README. The canonical, always-current setup reference lives at https://github.com/dmnd-pool/dmnd-client. The client ships new releases regularly, so if a flag, port, or step ever differs from what you read here, the README is the source of truth.

Most miners never choose the transactions in the blocks they find. The pool hands down a template, and the miner grinds on whatever the pool decided. Job Declaration flips that. You build your own block templates from your own node, and the pool pays you for the valid blocks you find. This is the first pool running Stratum V2 with JD end to end. This guide takes you from nothing to a working stack.

Why it matters

• Decentralization. Template construction moves from a handful of pools back to the individual miner.
• Censorship resistance. You build the template, so no intermediary can strip transactions before you mine them.
• Latency. Templates come from your own node, not over a link to the pool's server.

Your ASICs don't change

You do not reflash firmware or buy new hardware. The DMND Client accepts a standard Stratum V1 connection from your miners and handles all SV2 to the pool. Any stock firmware miner works.

How the pieces fit

┌─────────┐  SV1 (stratum+tcp)  ┌──────────────┐   SV2 + Job Declaration   ┌───────────┐
│  ASICs  │ ──────────────────► │ DMND Client  │ ────────────────────────► │ DMND Pool │
└─────────┘       :32767        └──────┬───────┘          :20000           └───────────┘
                                       │ templates
                                ┌──────┴───────┐    IPC     ┌──────────────┐
                                │    sv2-tp    │ ◄────────► │ Bitcoin Core │
                                │ (Template    │  (unix     │  (your node) │
                                │  Provider)   │   socket)  └──────────────┘
                                └──────────────┘
                                     :8336

A note on the name. You'll see the label "Job Declaration" (or "JD") on that middle arrow, and throughout the client README, the onboarding form, and the dashboard. It's the Stratum V2 protocol's term for the thing this whole guide is about: building your own blocks. Same concept, two names. We stick with the plain-English version in this post, but if you run into "Job Declaration" elsewhere, that's what it means.

• Bitcoin Core. Your node. It holds the mempool, and templates originate here. Pruned is fine.
• sv2-tp (Template Provider). Talks to Core over IPC, serves templates on port 8336.
• DMND Client. Pulls templates, declares them to the pool over SV2, accepts SV1 miners on 32767.
• DMND Pool. Reached outbound on 20000.

No inbound internet access is needed. You need only outbound to the pool (20000) and LAN access from miners (32767).

Before you start

• A machine that can run a Bitcoin node. Pruned is fine (a few GB disk), with 4 GB+ RAM.
• Bitcoin Core v30+ with multiprocess/IPC support.
• The DMND Client. Prebuilt binaries exist for most platforms, or you can build from source.
• A DMND token. Register at https://join.dmnd.work and wait for the confirmation email (check spam). You'll need it below.

---

Step 1: Your node and the Template Provider

This is the foundation JD sits on. There are two components.

1. Bitcoin Core v30+ with IPC enabled, your node. Pruned is enough (a few GB), while a full archival node (~800 GB) works but isn't required. sv2-tp talks to Core over its multiprocess/IPC interface, so earlier versions won't work.
2. sv2-tp (Template Provider), which connects to Core over a local IPC socket and serves templates on port 8336.

Running and syncing the node itself is outside this guide's scope. See the Bitcoin Core docs. What matters: v30+, IPC enabled, fully synced.

The sv2-tp README is the source of truth and stays current. It covers both enabling IPC on Core and running sv2-tp:

https://github.com/stratum-mining/sv2-tp#readme

Verify before moving on:

1. sv2-tp's log shows a successful IPC connection to Core and new templates as blocks arrive.
2. Node fully synced. Run bitcoin-cli getblockchaininfo. A mid-sync node is the most common reason the stack runs but produces no templates.
3. sv2-tp listening on 8336. Check with ss -tlnp | grep 8336.

Step 2: Get and run the DMND Client

Download the release binary from https://github.com/dmnd-pool/dmnd-client/releases. Verify checksums or signatures where provided, then run chmod +x dmnd-client. (From source: install rustup, clone the repo, run cargo build --release, and use ./target/release/dmnd-client.)

Run it:

TOKEN=<DMND-token> ./dmnd-client -l info -d <hashrate> --tp-address="127.0.0.1:<port>"

• <DMND-token> is the token from your registration email.
• <port> is the Template Provider port, default 8336.
• <hashrate> is the hashrate of your least powerful connected machine. It only seeds starting difficulty, and dynamic adjustment handles the rest. Use 250T for miners connecting directly, or 20P for aggregator proxies.

TOKEN=abc123 ./dmnd-client -l info -d 250T --tp-address="127.0.0.1:8336"

Verify: the log shows successful connections to both the Template Provider and the pool, with templates being declared.

Config precedence, highest wins: CLI flags, then config.toml, then environment variables. Watch for a leftover CLI flag quietly overriding your config file. Endpoint config (--api-base-url, --pool-address) is only needed behind a private gateway or proxy. By default the client discovers the pool and sends telemetry automatically.

Step 3: Connect your miners

Point your ASICs at the client machine:

stratum+tcp://<dmnd-client-machine-ip>:32767

• URL: the client machine's LAN IP, port 32767.
• Password: your DMND token.
• Username / worker: anything, or empty.

This is a standard SV1 connection with no firmware changes. Verify: miners connect almost immediately, and first shares are accepted within about 6 minutes. That delay is normal.

Step 4: Track it

Dashboard: https://dashboard.dmnd.work. Log in with your registration credentials. Hashrate is time averaged, so a low reading right after connecting is normal. Expect full hashrate within the hour.

Troubleshooting

Symptom	Cause	Fix
sv2-tp can't connect to Core	IPC off, or custom datadir	Follow sv2-tp README; check socket path
Client can't reach sv2-tp	Wrong --tp-address / not running	Confirm sv2-tp on 8336 (ss -tlnp | grep 8336)
Runs but no templates	Core still syncing	Wait for full sync (getblockchaininfo)
Miner connects, no shares	Normal within ~6 min	Wait
No shares after 10+ min	Wrong token, or -d far off	Re-check token; set -d correctly (250T / 20P)
Dashboard low/zero	Stats lag	Give it up to an hour

Still stuck? Use the support channel in your registration email.