IceRiver High Rejected Share Rate on Kaspa Pool (kHeavyHash)

Pull the power cord for a full 30 seconds, then power back on. A warm reboot via the Web UI is not enough to flush stuck stratum state on IceRiver firmware — the daemon caches DNS, pool state, and notify-job context. Cold pull clears all of it. Wait for fans to settle into steady-state and give it 10 minutes to negotiate a clean stratum session before checking the pool dashboard.

Re-enter the wallet address with the mandatory kaspa: prefix. Web UI > Pool Setting > erase the wallet field entirely > paste your full Kaspa address starting with kaspa: (lowercase, including the colon). Verify no trailing whitespace, no .workername appended (Kaspa pools use a separate worker-name field). Save. Power-cycle. Confirm the pool dashboard now shows accepted shares within 2-3 minutes. This single fix resolves roughly 40% of Kaspa reject-rate tickets we see at D-Central's bench.

Strip any difficulty parameter (d=NNNNN, +d=NNNNN) from the pool URL or wallet field. Modern Kaspa pools (Acc-Pool, Hash-Pool, WoolyPooly, F2Pool, Kryptex, ViaBTC) use vardiff and will land on a healthier per-worker target than any manual value. Static difficulty is a legacy practice from early Kaspa pools and a common cause of elevated reject rate today. Save, reboot, observe 10 minutes.

Configure a second pool slot pointing at a different Kaspa pool — Acc-Pool (kas.acc-pool.pw:6112), Hash-Pool (kas.hash-pool.com:5557), or WoolyPooly (kas.woolypooly.com:3112). Disable the original pool slot. Reboot with a 30-second power-cycle. Watch the new pool's worker dashboard for 15 minutes. If reject rate clears: original pool was misconfigured or in maintenance — keep the new one as primary. If reject rate persists across two pools: it's miner-side, keep going.

Confirm Temp1 and Temp2 land in the IceRiver-blessed 50-60 °C window. Web UI > Miner > Status. If Temp2 is below 50 °C (cold basement, unheated garage in winter, KS0 Ultra in particular): warm the room above 18 °C, insulate the intake, or place the miner in a smaller enclosed space so its own heat keeps it in band. If Temp2 is above 65 °C: clean intake filters, verify ambient < 35 °C, confirm fan RPM matches nameplate. Both extremes drive reject rate up.

Wire the miner. Disable WiFi, run a Cat5e or Cat6 cable straight from the router to the IceRiver's RJ45 port. Kaspa's 1-second block target does not tolerate the latency or jitter of consumer WiFi, powerline adapters, or double-NAT setups. Re-test reject rate over 30 minutes. Wired-vs-wireless is typically a 5-15% reject-rate swing on most Kaspa pools.

Override the router's DNS to 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google). Save router config, reboot router and miner. Canadian ISPs (Bell, Rogers, Vidéotron, Cogeco, Shaw, Eastlink) and rural US fixed-wireless / LEO satellite resolvers occasionally produce slow lookups for mining-pool hostnames. The symptom is intermittent reject spikes that disappear after the cache refresh. Same fix applies.

Run a 5-minute ping and mtr from a laptop on the miner subnet to your pool hostname. Healthy: avg < 80 ms, max < 150 ms, loss 0%. Anything worse, the network path is the bottleneck. Pick a geographically closer Kaspa pool: WoolyPooly (EU), F2Pool (Asia/global), Acc-Pool (regional). For Canadian or Northeast US miners, WoolyPooly EU node and F2Pool NA node usually win on latency.

Confirm chip count matches model nameplate. From a laptop: curl http://<miner-ip>/cgi-bin/get_miner_status.cgi (or read Web UI > Miner > Status). Per board: KS0 = 9 chips, KS3M = 26, KS5L = 52. If the count is below nominal (8/9, 25/26, 51/52), you have a partially failed hashboard producing reject-generating nonces. This is now a hashboard repair, not a pool problem. Skip to Tier 3 / Tier 4.

If you're on third-party OC firmware (rdugan, xyys, tswift), roll back to stock IceRiver firmware. Download from iceriver.io/firmware-download for your exact model and hardware revision. Flash via the Web UI over Ethernet only — IceRiver firmware upgrades over WiFi have a documented brick rate. Reboot. Retest reject rate over 30 minutes.

Reset the worker name to a unique, simple string (rig01, home-ks3m, no special characters). Some Kaspa pools dedupe worker entries by the (wallet, workerName) tuple; a stale worker registration from a previous owner or a previous setup can produce apparent rejects on the new one's first hours of mining. A clean worker name forces a fresh registration on the pool side.

Swap hashboards between slots. Power off, label slots 0/1/2 with tape, move the suspect board (the one lowering chip count or running hot) to a known-good slot. Power up, observe 30 minutes. If the low chip count or reject pattern follows the board: the board is the problem. If it stays in the slot: the control board, ribbon cable, or PSU rail to that slot is the problem. Cleanest single test before pulling boards for bench work.

Re-seat every hashboard data and power connector. Power off at the breaker. Disconnect each hashboard cable, inspect contacts for blackening, oxidation, bent pins. Reconnect firmly until you hear/feel the click. Listen during boot — fans should ramp clean, no unusual delays. Re-test reject rate. Loose connectors are a surprisingly common Kaspa-reject root cause on miners shipped from international resellers and on units that have moved between locations.

Refresh thermal paste on the affected hashboard(s). Pull the heatsink, clean old paste with 99% IPA + lint-free wipe, apply a thin uniform layer of Arctic MX-6 or Thermal Grizzly Kryonaut. Pay attention to thermal pads on the voltage-domain ICs and PCH — dried pads there are a common source of chip drift on aging KS-series. Reassemble, retest 30 minutes.

Inspect the hashboard under good light for bulging electrolytic capacitors, cracked MLCCs, burn marks, or solder joint failures near the 1004LV100 chips and LDO voltage-domain regulators. Bulged caps = end-of-life parts that produce voltage rail instability, which produces drift, which produces rejects. Time to bench (Tier 4) for component-level repair.

Run the 1004LV100 chip-test fixture if you own one (rare outside ASIC repair shops). Pull the suspect hashboard, mount on the test rig, run the per-chip enumeration sweep, identify the failing chip(s), document part position. Replacement chips (1004LV100) are available via Zeus BTC parts, but require a hot-air rework station and BGA-rework experience. If you don't own the bench, ship to D-Central.

Stop DIY when chip count remains permanently below nameplate after Tier 3, hashboard shows visible damage (bulged caps, burn, corrosion), bench-test isolates a 1004LV100 failure that needs reflow or replacement, or the KS5L/KS5M PSU shows the BP-H-3640 low-headroom failure pattern (random reboots under load, PSU hotter than the hashboards). Book at https://d-central.tech/services/asic-repair/.

What D-Central does on the bench: test fixture with programmable load, per-chip isolation on the hashboard, 1004LV100 replacement with verified chips, full reflow + reseal, post-repair 24-hour Kaspa-pool burn-in at nameplate. Canadian repair shop (no shipping-to-China customs lottery), bilingual EN/FR support, transparent quote before any parts swap, 5-10 business-day turnaround. Pack hashboards in anti-static bags, double-box with at least 5 cm of foam on every side, include a note with observed symptoms, firmware version, and your contact info.