Mining QUAI on a ZimaBoard2 — 100% GPU, 0% Accepted Shares (and the 690 That Fixed It)

“My GPU was running at 100% for hours. Hashrate 13.8 MH/s. Shares accepted: zero. This is the story of every lie a mining dashboard tells.”

The Bucket List Item

Everyone has that one weird bucket-list item. Mine was: mine a coin on hardware I own, with a node I built myself. Not “sign up for a pool and rent hashpower.” Actual metal in the actual house, talking to an actual chain I’m running.

The hardware: the same ZimaBoard2 that became my AI’s backup brain — except this time it’s not running a Discord twin, it’s running a go-quai node in Docker with chain data on a 4TB drive, plus an RTX 3060 hanging off it in an external enclosure. Same board, completely different job. That’s the thing about single-board servers: they moonlight.

The coin: QUAI, which was about to fork its mining algorithm to KawPoW — GPU-mineable, which means my 3060 finally had a reason to exist on that machine.

I want to tell you this ended with a triumphant first share within the hour. It did not. It ended with four separate traps, a 263GB rescue, and a mining binary that lied to my face for days. Let’s go through them in order, so you can skip all of them.

Trap #1: The Node Crawls From Genesis

Fresh go-quai node, no chain data. Sync progress: 0.4%.

At that pace, the KawPoW fork height (prime block 1,530,500) was months away. You cannot mine a fork you haven’t synced to — the node doesn’t even know the rules of the new block yet.

The fix is the standard one for big chains and it’s never fun: restore from a snapshot.

Imagine a screenshot here: terminal scrolling hundreds of .ldb filenames during snapshot extraction, with the extracted folder size showing 263G.

The snapshot ships as a 210GB tar.zst archive. Unpacked: 263GB of LevelDB files — prime/, region-0/, zone-0-0/ — extracted onto /media/sdb. The extraction took hours and the terminal spent all of them scrolling filenames like a slot machine that only pays out in .ldb.

What matters here:

• Don’t sync from genesis on a big chain. Ever. Find the official snapshot first.
• Budget the disk before you start — 210GB packed becomes 263GB unpacked, and the archive doesn’t delete itself unless you make it.
• A ZimaBoard2 with a 4TB drive handles this fine, but an eMMC-only board would have died mid-extract.

Trap #2: The Container Was Still Drinking From the Old Well

Snapshot extracted, container restarted, sync resumed. I checked the height. It was still crawling like genesis-sync.

Here’s the trap: the container was still mounted on the OLD data directory. The snapshot was sitting at /media/sdb/quai/mainnet-snapshot, but the container’s bind mount still pointed at /media/sdb/quai/node — the sad, half-synced original dir.

And while I’m confessing: I also tried to launch the node with setsid /media/sdb/quai/goquai-src/build/bin/go-quai and got a file-not-found — because there is no host binary. The node is a Docker container. I was trying to run a binary that only exists inside the image. docker inspect to find the actual runner, every time.

The fix was one flag on restart:

docker run ... -v /media/sdb/quai/mainnet-snapshot:/root/.local/share/go-quai ...

After the remount, the height jumped to prime 2,160,223 / zone 9.77M — past the fork. The node was suddenly a KawPoW-era node instead of an archaeology project.

What matters here:

• docker inspect before you assume anything about how the node runs. Don’t setsid host paths that don’t exist.
• Bind mounts are the #1 way Docker lies to you. The container will happily sync into an empty old directory forever if you let it.
• Verify the mount and the height after any data-dir surgery. The jump from 0.4% to 9.77M blocks is the sound of the mount being right.

Trap #3: Port 3333 Is Not For You (Probably)

Node synced, stratum enabled. I pointed the GPU miner at the node’s built-in stratum server — port 3333 — and got the most misleading success message in mining: “authorized, but zero jobs.”

Authorized! Great! Zero jobs! What?

Turns out the node’s StratumX serves three different algorithms on three different ports:

An RTX 3060 speaking KawPoW to a SHA-256 port is a handshake that technically succeeds and then never gives you work. “Authorized but zero jobs” doesn’t mean “you’re early” or “wait longer.” It means wrong port for your algorithm.

What matters here:

• GPU mining on QUAI (post-fork) = port 3335. Write it on your hand.
• There’s a second layer to this trap: StratumX serves no jobs at all pre-sync. If you’d hit 3335 with a node still at 0.4%, you’d get the same silent nothing. “No jobs” means either wrong port or unsynced node — check both.

Trap #4: The Official Docker Miner Images Don’t Exist Anymore

This one’s just funny. The QUAI docs reference quainetwork/quai-gpu-miner-run and -build on Docker Hub. Both return 404 — object not found. The images are gone. The docs still point at them.

So I built from source instead: quai-gpu-miner-nvidia-v0.5.0.tar.gz — the latest release from the official dominant-strategies/quai-gpu-miner repo. Latest release: January 2025. The repo’s been dormant since March. Remember that date, it becomes important in a second.

The Mystery: 100% GPU, 100% Rejected

Now the part that ate the most days.

quai-gpu-miner v0.5.0 — the official miner — fired up beautifully. GPU at 100%, 13.4–13.8 MH/s, ~141W, thermals fine. Jobs flowing. Shares submitting.

And every single share coming back rejected:

Accepted shares: 0
Rejected shares: 51   (A0:R51)
Error: mixhash mismatch

I did the classic miner griefing cycle:

1. “It’s my hashrate, shares just take time.” → No. Low hashrate means slow shares, not invalid ones.
2. “It’s the solo node being weird.” → Pointed it at StratumX EU (mining-eu.stratumx.org:3335) instead. Same result. 0 accepted, 51 rejected, mixhash mismatch every time.
3. “Wait it out.” → You can’t. A deterministic verification failure doesn’t age into a success.

Here’s what mixhash mismatch actually means: the miner computes the KawPoW mixhash one way, and the node/pool verifying it computes it another way. Every share is cryptographically wrong the moment it’s born. The GPU isn’t lazy — it’s signing documents in a language the bank stopped accepting.

The evidence pile got damning:

• v0.5.0’s mixhash doesn’t verify against go-quai v0.55.x solo stratum OR StratumX EU. Two independent verifiers, same rejection.
• The current QUAI docs’ list of supported KawPoW software is SRBMiner-Multi, Rigel, and WildRig Multi. The official quai-gpu-miner — the one the (stale) Docker docs reference — isn’t on the list. It’s a ProgPoW-era artifact that outlived its welcome.
• Kryptex’s official QUAI mining guide recommends Rigel for NVIDIA cards.

That 690/0 counter has since climbed to 2548 accepted / 0 rejected — the log above is the proof wall.

What matters here:

• mixhash mismatch = algorithm/version mismatch between miner and verifier, not a performance problem. No amount of waiting fixes it.
• “Official” and “current” are different words. The official miner was stale; the docs’ software list was the truth.
• A dashboard showing 100% GPU utilization tells you the hardware is fine. It says nothing about whether the work is valid.

The Fix: Rigel, and 690 Shares That Landed

The switch took minutes.

Rigel 1.23.2, pointed at StratumX EU on the correct port, wallet tagged …559B.worker001:

mining-eu.stratumx.org:3335

Rigel is CUDA-native — no OpenCL detour needed (that matters, see the SRBMiner footnote below). First share: accepted. Then it just… kept happening.

Accepted shares: 690
Rejected shares: 0

690 accepted. 0 rejected. 13.86 MH/s at 140W, GPU at a lazy 67°C. Same hardware that had been “mining” at 100% for days producing nothing.

And then the chain said it back. A coinbase transaction landed on the wallet: ~8.98 QUAI, block 9,935,090, from and to 0x0023…559B — visible on Quaiscan. Not a pool IOU. An actual block reward, paid by the chain, to the address I chose, from hardware on my desk. The bucket-list item didn’t end at “shares accepted” — it ended with the blockchain itself shaking my hand.

The pool’s 7-day earnings view confirms what the log already said: 2 blocks found by worker001, 24.79 QUAI total. (The 8.98 QUAI block from the original post is in there.)

The complete accepted-shares wall — Rigel log, 2026-09-06 — is the receipt. 2548/0 at 13.86 MH/s.

The pool-side view tells the fuller story. 2,570 valid shares submitted, 1 worker active, 12.89 MH/s steady — but also 290 invalid, a 10.14% rejection rate. The Rigel log’s own count shows Rej: 0; the pool disagrees. That gap is the post-smoking-gun: something between the miner and the pool is still generating bad shares, or the pool is flagging old-history rejects that never hit the log. Same wallet, same worker, two different stories from the same math. The bucket-list item is proven, not closed.

The bucket-list item is functionally done: own hardware, own node (synced and healthy on the snapshot, height past 9.77M zone blocks), and shares verifiably landing on the pool. The last honest caveats: shares currently verify against StratumX EU, not my local node’s solo stratum — solo verification with Rigel is the next experiment — and the pool’s 10% rejection rate needs explaining. The node objective was achieved; the pool objective was proven.

How to check your own setup (the cheat sheet I wish I’d had):

# GPU reality check
nvidia-smi                          # util%, temp, power draw

# Live share feed — the only truth that matters
tail -f /path/to/rigel.log          # every accepted/rejected line lands here

# Rigel's built-in stats page (port shown at startup / --api-port)
# http://<miner-ip>:<api-port>

# Pool-side dashboard (StratumX): hashrate, accepted, payouts per worker

Rule of thumb: nvidia-smi tells you the hardware is alive. The log tells you the work is real. Only ever trust the second one.

Footnote: The SRBMiner Path Not (Yet) Taken

For completeness: SRBMiner-Multi 3.6.1 refuses to run on the Zima (“Unsupported runtime environment”) — 3.6.2 runs, but the board only has an Intel OpenCL ICD installed, so --gpu-id 0 comes back “no GPU backend.” The fix path is documented (drop in the NVIDIA OpenCL .so + write /etc/OpenCL/vendors/nvidia.icd, needs sudo), but Rigel made it moot — CUDA needs no OpenCL plumbing at all. Parked, not abandoned.

What We Learned

1. Snapshot first, sync never. 210GB of compressed chain beats months of crawling from genesis. Budget disk, verify the mount, check the height jumped.

2. Docker lies through its mounts. The container syncing the wrong directory was silent — no error, just eternal 0.4%. When progress looks impossible, verify the bind mount before blaming the chain.

3. Ports are algorithms. 3333/3334/3335 on QUAI’s StratumX are SHA-256/Scrypt/KawPoW. “Authorized but zero jobs” is almost always one of: wrong port, or unsynced node.

4. Check the docs’ software list, not the repo’s release page. The official miner’s last release was January 2025; the current docs already list its replacements. When every share fails with the same error on two different verifiers, the binary is the bug. Rigel for NVIDIA took minutes and went 690/0.

5. A busy GPU is not a mining GPU. 100% utilization at 13.8 MH/s and 0 accepted shares is a heater, not a miner. The accepted counter is the only scoreboard.

“They gave me a miner that computed the right answer in the wrong language, and called it official. You know what fixed it? Reading the docs’ software list like it was an escape route. Six hundred and ninety shares later, I’m still here. The machine never slept. It was just never speaking the chain’s language.”

— Cleetus 🤡

P.S. — The ZimaBoard2 now holds two jobs: backup AI brain and mining rig. $119 board, and it refuses to have a single career. Same energy as its owner.

P.P.S. — If you’re setting this up yourself: snapshot, mount check, port 3335, Rigel. Four things. Skip all four traps and your first accepted share takes an afternoon instead of a saga.

#mining #quai #kawpow #zimaboard #rigel #selfhosting #gpu