---

Author: HazenNetworkSolutions Network: Quantus Mainnet (--chain mainnet) Versions: quantus-node v1.0.1+ · quantus-miner v4.2.x · pool miner 6.2.0 Last Updated: September 2026

---

Table of Contents

Read first

• How Mining Works
• The Two Routes — A or B
• Hardware Requirements
• Ports and Endpoints

Shared setup — everybody does this

• Step 1 — Create a Wallet
• Step 2 — Verify the GPU (Linux)
• Decision Point — Pick Your Route

Then one route, not both

• Part A — Pool Mining (Quanpool PPLNS)
  • A1 — Install the Pool Miner
  • A2 — Benchmark the Card
  • A3 — Token and TLS Pin
  • A4 — First Manual Run
  • A5 — systemd Service
  • A6 — Verify on the Pool
  • Part A Finish Line
• Part B — Your Own Node
  • B1 — Automated Setup Script
  • B2 — Manual Install: Binaries
  • B3 — Node Identity and Wormhole Inner Hash
  • B4 — Start the Node
  • B5 — Start the External Miner
  • B6 — Updating a Node/Miner Pair
  • Part B Finish Line

Reference — both routes

• Monitoring and Everyday Commands
• Performance Reference
• Firewall
• Running Multiple Machines
• Troubleshooting
• Economics — What to Expect
• Switching Routes Later

---

How Mining Works

Quantus mining always involves two jobs, and the split explains everything that follows:

1. The node (quantus-node) connects to mainnet, keeps a full copy of the chain, assembles block candidates and hands out mining jobs. Started with --miner-listen-port, it also becomes a QUIC server on port 9833.
2. The miner does nothing but search for a winning nonce, on GPU or CPU. The miner is always the client: it dials the node, never the reverse.

The algorithm is QPoW — double Poseidon2 hashing instead of SHA-256. A nonce wins when Poseidon2(Poseidon2(block_hash ‖ nonce)) lands below the difficulty target. Poseidon2 was chosen because it is cheap to verify inside a ZK circuit, not because SHA-256 is weak.

The node's built-in CPU miner exists for testing — roughly 15 MH/s per thread. Real throughput comes from an external GPU miner, 500 MH/s – 1.5 GH/s per modern card. Several miners may connect to one node; the first valid result wins.

The key question is who runs job 1. Run the node yourself and you own the whole pipeline. Join a pool and the operator runs it for you, while your miner dials out to host:9834 over UDP — which is why pool mining works behind CGNAT with no port forwarding, no static IP and no chain sync.

Either way, rewards never land on a regular address. The protocol pays a wormhole address derived from a 32-byte preimage called your inner hash. Derive it from the same 24 words as your wallet app and the rewards appear there, spendable, with no claim transaction.

Chain facts worth knowing

⚠️ Always pass --chain mainnet. planck is the retired testnet: separate chain, separate database, no balance migration. Never copy chains/planck/ into chains/mainnet/, and never pass --force-authoring on mainnet — that flag is for bootstrapping a brand-new network.

---

The Two Routes — A or B

Two mutually exclusive halves. Read this before installing anything: the choice changes what you download, what you open on your firewall and how you get paid.

Part A — Pool Mining

You run only a miner. It connects outbound to a pool operator's node, works the jobs that node sends, and submits shares. The pool finds blocks and splits rewards by share count (PPLNS).

• You install: one binary, one systemd service.
• You need: a qz… address, a GPU, outbound UDP.
• You do not need: a synced chain, disk space, open inbound ports, a public IP.
• You get paid: small amounts, continuously, once past the payout threshold.
• Time to first hash: 15–30 minutes.

Part B — Your Own Node

You run both jobs on your own hardware: quantus-node syncing mainnet, plus quantus-miner pointed at it on 127.0.0.1:9833.

• You install: two matched binaries, node identity, wormhole inner hash.
• You need: 100 GB+ SSD, stable bandwidth, patience for the initial sync.
• You get paid: the whole block reward when your node wins — and nothing in between.
• You also get: zero fees, full custody, no trust in an operator, and a node that strengthens the network.
• Time to first hash: a few hours, mostly sync time.

Side by side

Which one should you pick?

Pick Part A if any of these is true — and at home, usually one is:

• You have one or two consumer GPUs rather than a farm.
• You are behind CGNAT, a mobile connection, or a router you do not control.
• You want income within the week instead of waiting for luck.
• You do not want a process that has to stay synced.

Pick Part B if:

• You wanted to run a Quantus full node anyway.
• You have enough hash rate that block variance is tolerable.
• You refuse to route rewards through a third party.
• You are on a server with a real IP, an SSD and no bandwidth cap.

The decision is not permanent. Wallet, address and GPU work are identical in both routes — see Switching Routes Later.

How this guide is laid out

  Step 1  Create a wallet          ─┐
  Step 2  Verify the GPU            ├─ everybody does these two
                                    │
  ── Decision Point ──────────────┘
         │
         ├── Part A  A1 → A6   ends at "Part A Finish Line"
         │
         └── Part B  B1 → B6   ends at "Part B Finish Line"
                 │
  Reference sections apply to whichever route you finished

Do exactly one part. Both on one machine means two miners fighting over one GPU; neither performs.

---

Hardware Requirements

• Hash rate is decided by the GPU and the miner build, not disk size or CPU cache. A large-cache CPU does not accelerate Poseidon2.
• QPoW is not VRAM-hungry. 8–12 GB is plenty; a 140 GB datacenter card is not "50× faster" and usually loses on cost per hash to a consumer 4090.
• The node database is RocksDB and does random I/O. Any SSD works; an HDD stalls the sync.
• Linux ARM64 has no official miner binary — mine from Linux x86_64 or macOS. AMD GPUs do not work with the CUDA pool miner.
• Part A needs none of the disk or bandwidth headroom above — only the GPU and outbound UDP.

---

Ports and Endpoints

All official links live in README.md.

---

Where to Start

---

Shared Setup

Both routes start here. Two steps, then you choose.

Step 1 — Create a Wallet

You need a qz… address before anything else. Both routes use the same wallet and the same 24 words.

1. Install the Quantus Wallet (iOS / Android — links also on linktr.ee/quantusnetwork).
2. Create a wallet and write the 24-word phrase on paper, offline.
3. The address on the main screen starts with qz…. That is the only value you ever paste into a pool form or a lookup box.

CLI alternative:

# from https://github.com/Quantus-Network/quantus-cli/releases
quantus wallet create --name mining

CRITICAL: the 24 words are the only recovery path for your rewards. Never type them into a chat window, a pool form or a rented server. Part A needs your address; Part B needs the inner hash derived from those words.

Done when: you can read a qz… address off the screen and the 24 words are on paper.

---

Step 2 — Verify the GPU (Linux)

Confirm the proprietary NVIDIA driver is active before installing any miner. A miner on the wrong driver path silently runs 4–6× slow.

No Linux yet? Do ubuntu.md first — it hands back here. On a rented GPU the driver is already injected by the host: use vast.md.

sudo apt update && sudo apt upgrade -y
sudo apt install -y ubuntu-drivers-common wget curl ca-certificates netcat-openbsd jq

# only if the driver is missing
sudo ubuntu-drivers autoinstall
sudo reboot

After the reboot:

nvidia-smi
nvidia-smi -L      # one line per GPU

You should see the card name, the driver version and a CUDA Version column. Low utilisation is expected — no miner is running yet.

You do not need the full cuda-toolkit; the prebuilt miners carry their own CUDA runtime. If nvidia-smi prints nothing, disable Secure Boot (or enroll the MOK key) and reboot. RTX 50-series (Blackwell) needs a recent kernel and a 570+ driver.

Done when: nvidia-smi -L lists your card(s) by name.

---

Decision Point — Pick Your Route

Shared setup is finished. Everything below is one route or the other.

Still unsure? Do Part A. It is reversible in an hour, it proves your card and address work, and it starts paying while you think.

---

Part A — Pool Mining (Quanpool PPLNS)

Prerequisites: Step 1 (a qz… address) and Step 2 (a working GPU driver). Ends at: Part A Finish Line. You will not touch: quantus-node, chain sync, inbound firewall rules, or an inner hash.

Quanpool is a community pool, not official Quantus infrastructure. Host address, download link and TLS pin are published live on quanpool.com → Start mining. Copy them from there every time; the values below are placeholders on purpose.

A1 — Install the Pool Miner

sudo mkdir -p /opt/quantus
sudo chown "$USER:$USER" /opt/quantus
cd /opt/quantus

wget -O quanpool-miner https://download.quanpool.com/quanpool-miner-6.2.0-linux-x86_64
chmod u+x quanpool-miner
./quanpool-miner --version

If that version 404s, take the current Linux link from Start mining (6.1.0 also works).

The gpu-list subcommand was removed in 6.1+. Enumerate cards with nvidia-smi -L.

A2 — Benchmark the Card

A benchmark runs locally and never contacts the pool. Do it before any pool configuration — it answers the most expensive question in this guide: whether you are on the CUDA code path at all.

cd /opt/quantus
./quanpool-miner benchmark --gpu-devices 1 --cpu-workers 0 --duration 30

Treat --cpu-workers 0 as mandatory on a desktop. CPU mining adds ~15 MH/s per thread — negligible next to the card, while stealing the threads that feed it.

A3 — Token and TLS Pin

On quanpool.com → Start mining, fill in:

There is no sign-up and no password: the address is the account. Copy the --node-addr (prefer the literal IP:9834 over a hostname) and the 64-hex --tls-cert-sha256 value into files, so they never reach your shell history:

cd /opt/quantus

# one single line: qzYOURADDRESS.workername
nano auth-token

# the 64-hex TLS pin from Start mining
nano tls-cert-sha256

chmod 600 auth-token tls-cert-sha256

A4 — First Manual Run

Run it in the foreground once so you can read the errors, before handing it to systemd.

cd /opt/quantus
./quanpool-miner serve \
  --node-addr <POOL_HOST>:9834 \
  --auth-token-file /opt/quantus/auth-token \
  --tls-cert-sha256-file /opt/quantus/tls-cert-sha256 \
  --cpu-workers 0 \
  --gpu-devices 1 \
  --mode pool

Replace <POOL_HOST> with the address from Start mining, and set --gpu-devices to the card count from nvidia-smi -L (omit the flag to use all of them).

Healthy signs within the first minute:

• nvidia-smi shows the miner process and 95–100% GPU utilisation
• the log prints job lines and SHARE FOUND
• curl -s http://127.0.0.1:9900/hive-stats returns a populated hs and an ar with zero rejects

A burst of SOLUTION LOST / stale messages in the first seconds is normal while the miner catches up to the current job.

Stop with Ctrl+C once it looks healthy — the next step makes it survive reboots.

A5 — systemd Service

sudo tee /etc/systemd/system/quanpool-miner.service >/dev/null <<EOF
[Unit]
Description=Quantus pool miner (Quanpool PPLNS)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=$USER
WorkingDirectory=/opt/quantus
ExecStart=/opt/quantus/quanpool-miner serve --node-addr <POOL_HOST>:9834 --auth-token-file /opt/quantus/auth-token --tls-cert-sha256-file /opt/quantus/tls-cert-sha256 --cpu-workers 0 --gpu-devices 1 --mode pool
Restart=always
RestartSec=8
Nice=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now quanpool-miner
sudo systemctl status quanpool-miner --no-pager
journalctl -u quanpool-miner -f

Edit <POOL_HOST> in ExecStart before starting. auth-token is mode 600, so it must be readable by the User= you set here.

A desktop must also stop suspending, or the GPU halts when the screen blanks:

gsettings set org.gnome.desktop.session idle-delay 300
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'

A rented container usually has no working systemd. Use the image's process supervisor instead — see vast.md.

A6 — Verify on the Pool

Locally first:

curl -s http://127.0.0.1:9900/hive-stats

hs is usually kH/s — 430000 ≈ 430 MH/s. ar is [accepted, rejected] and rejected should stay at zero; temp, fan and pool_rtt_ms are also reported.

Then open quanpool.com, paste your qz… address into the lookup box and press Look up. Your worker appears within a few minutes, with its own hash rate, share count and a growing pending balance.

Ports 9900, 9833, 9944 and 9615 must never be published to the internet. A router "virtual server" rule for them achieves nothing and creates real exposure.

Part A Finish Line

Complete when all four are true:

1. systemctl status quanpool-miner reports active (running) and survives a reboot.
2. nvidia-smi shows 95–100% utilisation at the hash rate from your A2 benchmark.
3. hive-stats shows accepted shares climbing and rejected staying at zero.
4. Your worker is visible on the pool lookup page and the pending balance is rising.

Nothing else to install: no node, no sync, no inner hash. Continue to Monitoring, Running Multiple Machines or Economics. Skip Part B unless you later decide you want your own node — then read Switching Routes Later first.

---

Part B — Your Own Node

Prerequisites: Step 1 (the 24 words — you derive the inner hash from them), Step 2 (a working GPU driver), a 100 GB+ SSD and bandwidth you can leave running. Ends at: Part B Finish Line. Two ways through: B1 is the official script and does everything for you. B2–B5 are the manual equivalent. Do B1, or do B2–B5 — not both. B6 applies either way.

No pool fees and full custody, at the cost of a full chain sync and a matched binary pair. Works on Linux, macOS and WSL2.

B1 — Automated Setup Script

The official script generates the wormhole inner hash and node identity, downloads a matched pair into ~/quantus-mining/bin/, and writes ~/quantus-mining/mining.conf with CHAIN=mainnet.

curl -fsSL https://docs.quantus.com/scripts/quantus-mining.sh -o quantus-mining.sh
chmod +x quantus-mining.sh
./quantus-mining.sh setup
./quantus-mining.sh start -d

Day-to-day control:

./quantus-mining.sh start          # node foreground, miner background
./quantus-mining.sh start-node     # one terminal
./quantus-mining.sh start-miner    # second terminal, after the miner server listens
./quantus-mining.sh stop
./quantus-mining.sh config show
./quantus-mining.sh config set GPU_DEVICES 1
./quantus-mining.sh config set CPU_WORKERS 0

Pin an explicit pair instead of letting two latest tags drift apart:

./quantus-mining.sh config set NODE_VERSION v1.0.1
./quantus-mining.sh config set MINER_VERSION v4.2.0
./quantus-mining.sh stop
./quantus-mining.sh setup --force
./quantus-mining.sh start -d

--force refreshes binaries only: it keeps your INNER_HASH and wormhole address and does not generate a new keypair. The script reads the node's miner-auth-token and miner-tls-cert-sha256 itself, so you never copy those by hand. Docker mode has been removed.

If the script covered you, stop here and jump to the Part B Finish Line. B2–B5 build the same result by hand — useful when you want control over paths, versions and service management, or when the script fails on your distro.

B2 — Manual Install: Binaries

sudo apt update
sudo apt install -y curl wget tar unzip jq screen ufw ca-certificates
mkdir -p ~/quantus && cd ~/quantus

wget https://github.com/Quantus-Network/chain/releases/download/v1.0.1/quantus-node-v1.0.1-x86_64-unknown-linux-gnu.tar.gz
tar -xzf quantus-node-v1.0.1-x86_64-unknown-linux-gnu.tar.gz
chmod +x quantus-node
./quantus-node --version

wget https://github.com/Quantus-Network/quantus-miner/releases/download/v4.2.0/quantus-miner-linux-x86_64 -O quantus-miner
chmod +x quantus-miner

Check Releases for current tags — official guidance is node v1.0.1 or newer, and the two repositories version independently.

Confirm the pair speaks the authenticated protocol before going further — both commands must print a match:

./quantus-node --help | grep miner-auth-token-file
./quantus-miner serve --help | grep auth-token-file

On macOS, clear the Gatekeeper flag first: xattr -d com.apple.quarantine quantus-node.

B3 — Node Identity and Wormhole Inner Hash

./quantus-node key generate-node-key --file node_key.p2p
./quantus-node key quantus --scheme wormhole --words

--words prompts for your 24 words without echoing them, so the phrase never lands in your shell history. Save the values it prints:

Using the same 24 words as your wallet app is the recommended path — rewards then show up in the app automatically. To mine to a brand-new wallet instead, run ./quantus-node key quantus --scheme wormhole and back up the phrase it generates. Reward routing to a wormhole address is not optional; it is built into the protocol, which is also why your mining identity is not linked on-chain to your payout address.

B4 — Start the Node

screen -S quantus-node
cd ~/quantus
./quantus-node \
  --name <YOUR_NODE_NAME> \
  --validator \
  --miner-listen-port 9833 \
  --chain mainnet \
  --node-key-file node_key.p2p \
  --rewards-inner-hash <YOUR_INNER_HASH> \
  --max-blocks-per-request 64 \
  --sync full

--name is how your node appears on telemetry.

On first start with --miner-listen-port, the node writes the miner auth material into the chain directory:

⚠️ Wait for a full sync before expecting rewards. Blocks mined before you reach the tip are orphans and earn nothing; the miner pauses by itself when the node has no peers. You are synced when the log switches from Syncing to Idle at the current height — typically 15 minutes to a few hours. discarding proposal during sync is normal. A stall with Verification failed and 0 peers means your node version is out of step — check Releases.

Also wait for the log line confirming the miner server is listening. If miner-server startup fails the node exits — there is no fallback to local mining.

B5 — Start the External Miner

In a second terminal:

screen -S quantus-miner
cd ~/quantus
CHAIN_DIR="$HOME/.local/share/quantus-node/chains/mainnet"

./quantus-miner serve \
  --cpu-workers 0 \
  --gpu-devices 1 \
  --node-addr 127.0.0.1:9833 \
  --auth-token-file "$CHAIN_DIR/miner-auth-token" \
  --tls-cert-sha256-file "$CHAIN_DIR/miner-tls-cert-sha256"

Variants: add --cuda-gpu on an NVIDIA card where Vulkan is unavailable; use --cpu-workers 4 --gpu-devices 0 on a machine without a usable GPU; add --gpu-throttle-ms 50 (or 5 if you also use the desktop) to cap heat and power draw.

Always use --auth-token-file / --tls-cert-sha256-file rather than the inline forms. A wrong token or pin is a permanent error: the miner stops instead of reconnect-looping. Re-read the files.

On macOS quote CHAIN_DIR — the path contains a space.

B6 — Updating a Node/Miner Pair

Applies to both the scripted and the manual install:

1. Stop the node first, then the miner.
2. Download a matched pair — both must ship quantus-miner/2.
3. Keep .../chains/mainnet/. Never import a chains/planck/ directory.
4. Start the node, wait for the miner server to listen, then start the miner.

Part B Finish Line

Complete when all five are true:

1. The node log reads Idle at the current chain height, with a stable peer count.
2. Your --name is visible on telemetry.quantus.cat.
3. The node logged that the miner server is listening on 9833.
4. The miner is connected, nvidia-smi shows 95–100% utilisation, and the node log shows Broadcasting job.
5. ufw status allows 22/tcp and 30333/tcp and nothing else.

Rewards now arrive as whole blocks, irregularly, at the wormhole address from B3 — check it in the wallet app or the explorer. Continue to Monitoring, then Economics so the silence between blocks does not worry you.

---

Reference

Applies to whichever route you finished.

Monitoring and Everyday Commands

Part A — pool

sudo systemctl status quanpool-miner --no-pager
sudo systemctl restart quanpool-miner
journalctl -u quanpool-miner -f
curl -s http://127.0.0.1:9900/hive-stats
nvidia-smi --query-gpu=index,temperature.gpu,utilization.gpu,power.draw,fan.speed --format=csv

# re-benchmark, or test outbound UDP (no reply from nc is not proof of failure)
./quanpool-miner benchmark --gpu-devices 1 --cpu-workers 0 --duration 30
nc -zvu <POOL_HOST> 9834

The pool's lookup page shows workers, pending balance and payouts. To update the binary: stop the service, download the new file, chmod +x, start again.

Part B — own node

./quantus-node --version
./quantus-node key inspect-node-key --file node_key.p2p
tail -f ~/.local/share/quantus-node/chains/mainnet/network/quantus-node.log

A healthy node shows a stable peer count, Idle at the tip, Prepared block for proposing and Broadcasting job.

---

Performance Reference

Published figures for the Linux CUDA pool miner versus the stock miner, GPU only. Always confirm your own card with benchmark --duration 30.

Rough expected income, ignoring fees and luck:

daily QTC ≈ (your H/s / network H/s) × (86400 / block_seconds) × block_reward

Every term moves. Difficulty re-adjusts on each finalized block, so a single consumer card is a small fraction of a network measured in TH/s. Treat any fiat figure as unverified.

Thermals: a 24/7 mining card sits near its power limit with fans up. Sustained ~70 °C is normal, well below the ~83–88 °C throttle point; dust and case airflow are the real maintenance items. If the card holds 85 °C continuously, add --gpu-throttle-ms 5.

---

Firewall

Part A needs no inbound rules at all — only outbound UDP to the pool port. If your router or ISP blocks outbound UDP/QUIC, the miner loops on reconnect; test from a phone hotspot to confirm.

Part B:

sudo ufw allow 22/tcp
sudo ufw allow 30333/tcp
sudo ufw enable
sudo ufw status verbose

Do not open 9833, 9944 or 9615. For a remote miner, join it to the node over WireGuard or Tailscale and keep the miner port private.

Behind CGNAT (most mobile and many fibre home connections) inbound 30333 never arrives — the rule is harmless but does nothing, and the node still syncs through outbound connections. Port forwarding cannot fix CGNAT; only a public IP or a VPN endpoint can. This is precisely why Part A is the easier home route.

---

Running Multiple Machines

Several miners can pay into the same qz… address; PPLNS shares add up.

• Give every machine a different worker name. Reusing one name makes two rigs collide and one disappears from the pool.
• You do not need to stop the home rig to add a second one.
• Never copy your seed to a rented machine. A rented box only needs qzADDRESS.worker and the TLS pin — see vast.md.
• On the Part B side the equivalent is several miners dialling one node on 9833 over a VPN. The node broadcasts jobs to all of them and the first valid result wins.

---

Troubleshooting

Part A — pool route

Part B — own node route

On Windows, exclude the node data directory from Defender before syncing:

Add-MpPreference -ExclusionPath "$env:USERPROFILE\.quantus"

Pre-auth releases (node v0.9.0, miner v3.3.1 and earlier) have no miner authentication. Do not use them against current mainnet.

---

Economics — What to Expect

Emission. Block rewards follow (MaxSupply − CurrentSupply) / EmissionDivisor — smooth exponential decay of a fixed 21,000,000 supply, with no halving cliffs. Miners receive 50% of total supply over time and roughly 99% of all supply is emitted within about 40 years. A dev tax allocates 15% of block rewards to the company, vesting over years.

On-chain fees. Standard transfers pay a fixed fee that goes to the miner. High-security reversible transfers pay a volume-based fee that is burned, and ZK-aggregated transactions pay a smaller volume fee split between the miner and a burn. Mining income therefore comes overwhelmingly from emission, not from fees.

Part A — how PPLNS pays. You are paid per share, not per block. No block is ever "yours"; your balance accrues continuously and that is the whole point — it removes variance. The pool charges a flat fee and pays out above a single threshold; both are published on the pool site and both have changed over time, so read them there rather than trusting a number in any guide, including this one. Solo mode inside a pool carries the same fee but pays like a lottery.

Part B — how solo pays. Zero fees, full custody, and one whole block reward whenever you win. With a single consumer card against a network measured in TH/s, that can mean long silences. Nothing is wrong; variance is the price of not sharing.

What moves your income. Difficulty re-adjusts on every finalized block, so a rising network hash rate lowers your daily QTC even if your rig never changes. Measure with benchmark, then compare against the pool's live network hash rate.

QTC market data is thin, and the unit is labelled QUAN in parts of the official docs and tooling. Treat any fiat projection as speculative.

---

Switching Routes Later

The two routes share the wallet, the address and the GPU work, so moving between them is cheap.

A → B (pool to own node)

sudo systemctl disable --now quanpool-miner

Then start at B1. Derive the inner hash from the same 24 words and rewards keep landing in the same wallet app. Leave any pending pool balance alone — it pays out on the normal schedule.

B → A (own node to pool)

Stop the miner, then the node. Keep chains/mainnet/ if you might come back; it saves the resync. Then start at A1 using the same qz… address.

Running both at once is not a strategy. Two miners on one GPU halve each other. With two cards, give each route its own card via --gpu-devices and separate services — otherwise pick one.

---

Next Steps

---

About the Author

Prepared by HazenNetworkSolutions. 🌐 hazennetworksolutions.com