Goldshell – High Share Rejection / Stale Rate
Warning — Should be addressed soon
Symptoms
- Dashboard `Reject` percentage reads above 2% sustained for 30+ minutes (Goldshell UI shows `Accepted` / `Rejected` / `Stale` counters in the Miner Status section)
- Pool-side effective hashrate is 5-25% below the miner-side dashboard hashrate over a 24-hour window
- `Stale` counter climbs faster than `Rejected` — points at latency / late nonces
- `Rejected` counter climbs faster than `Stale` — points at malformed nonces / chip drift
- Reject% spike correlates with a recent overclock, mode change, or firmware update — sudden onset
- Reject% climbs gradually over weeks or months with no config change — points at thermal paste degradation or chip aging
- Reject% is worse during specific hours (peak evening, hot afternoons) — environmental / network
- On multi-board models (LT5/LT6/CK6/KD6/HS5), one board's per-board hashrate is 5-15% below the others
- Pool worker view shows the worker as `online` continuously, no flap, but the share rate is suppressed
- Miner is on a pool endpoint geographically far from its location (e.g. NA miner pointed at an Asia-region endpoint)
- Miner is behind a VPN, double-NAT, or commercial-grade firewall adding 50+ ms or dropping packets
- Reject% jumped immediately after flashing a new firmware that lists `stratum changes` or `share submission` in the changelog
Step-by-Step Fix
Hard power-cycle for 60 seconds at the wall. Pull the C13 / barrel jack, wait a full minute so the bulk caps drain, re-energize. Clears wedged stratum-client state and any half-open TCP sockets. Roughly 10% of `high reject%` cases are a wedged client that a cold reboot fixes.
Switch to a regional pool endpoint. In Miner Config, change the stratum URL to a pool PoP geographically near you: F2pool regional (`kda-na.f2pool.com:6400`, `kda-eu.f2pool.com:6400`, etc.), ViaBTC anycast (`kda.viabtc.com:6700`), or Dxpool (`dxpool.net:9008`). Save, reboot, watch 30 minutes. Single highest-leverage change for Goldshell reject%.
Drop the mode to stock or eco. From `Performance` or `Custom` back to `Stock`. Save, reboot, watch 30 minutes. If reject% returns to under 1.5%, your tuning was beyond the chip's stable ceiling. Rebuild slower in Tier 3, one frequency step at a time.
Set DNS to public resolvers. In Network Config, set DNS1 `1.1.1.1`, DNS2 `8.8.8.8`. Reboot. Fixes `intermittent stratum hostname resolution` failures that present as elevated stale shares. Goldshell defaults to ISP DNS, which is sometimes slow or wrong.
Reboot the router and the miner together. Power off both, wait 90 s, router on first, wait 2 min for DHCP/DNS to stabilise, miner on. Consumer-router connection-tracking tables overflow over weeks of uptime; a monthly reboot is cheaper than a stale-share habit.
Run a 24-hour ping test to the pool from a same-LAN laptop. `ping -t <pool-host>` on Windows, `ping <pool-host>` on macOS/Linux. Log RTT and packet loss. Cross-reference time-of-day against your reject% logs. ISPs deprioritize stratum traffic at peak hours on some last-mile cable plants — measurable pattern in Canadian residential service.
Move the miner off WiFi to ethernet. Cat5e/6 from router to miner. Goldshell radios are weak; on a congested 2.4 GHz band, packet loss spikes drive stale shares without obviously failing. Goldshell's own KB requires ethernet for firmware updates; same logic applies to steady-state mining on the older BOX hardware.
DHCP-reserve the miner's MAC at the router. Bind the Goldshell's MAC to a fixed IP. Kills the `lease churn` class of intermittent disconnect that lands as stale shares. Three minutes of router admin work that solves an entire failure mode.
Measure PSU rail under load. Multimeter on DC, probe the 12 V output while the miner is hashing at full power. Expect ≥11.8 V sustained on KD-BOX class, ≥12.0 V on LT/CK/HS class. Below = PSU sag = voltage regulator glitches the hashboard = bad nonces submitted = reject% climbs. Swap with a known-good PSU sized 1.3x nameplate (1800 W+ for LT5/LT5 Pro, 2200 W+ for LT6/CK6/HS5).
Measure wall voltage during peak evening hours. Voltage logger across the outlet for 24 hours. Sub-228 V on 240 V split-phase or sub-112 V on 120 V residential during peak = your circuit is the bottleneck, not the miner. Move to a dedicated 240 V branch circuit before tuning further.
Flash the latest stable Goldshell firmware over ethernet. Pull the current release for your exact model from `github.com/goldshellminer/firmware`. System → Update Firmware → upload `.bin` → don't touch the device for 5-10 minutes. Confirm version after reboot. Avoid suspect builds: KD-BOX `2.1.1` / `2.1.3` (per GitHub Issue #50 — chip-init regression that elevates apparent reject%); any pre-`2.2.3` algo-switch build on multi-algo models. If the current build introduced reject% issues for you, roll back one point release.
Per-board chip-position isolation. On multi-board models, disconnect boards one at a time (power off for each swap). Run the miner with one board at a time for 30 minutes each, log the reject% per board. The board that drives the system-wide reject% above 3% is the culprit. Single-board models (KD-BOX, Mini-DOGE, HS-BOX) — skip this; the failure is at the chip level and you need a bench fixture.
Refresh thermal paste. Pull the heatsink off the suspect board, clean the chip and heatsink mating faces with 99% IPA + lint-free wipes, apply Arctic MX-6 or Thermal Grizzly Kryonaut in a uniform thin layer (don't glob it on), re-mount with even torque. Dried paste from 18+ months of 24/7 operation is a top-3 cause of gradual reject% climb across the entire Goldshell repair queue at D-Central.
Rebuild OC slowly from stock baseline. Set mode to `Stock`. Verify reject% under 1.5% over a 30-minute window. In `Custom` mode (where supported), bump frequency one step (typically 25 MHz), wait 20 minutes, check reject%. Stop at the step before reject% crosses 2%. That is this individual chip's silicon-lottery ceiling — every die is different, even within the same model batch.
SSH access for power users. On rooted Goldshell firmware (procedure documented in the Andreas Mai Goldshell internals research), pull `/var/log/messages` and the cgminer-equivalent process logs to see actual share-submission errors and per-chip nonce counts. Advanced terrain — improper SSH config has historically left BOX miners exposed to pool-hijack botware. Harden SSH (key auth, no port-forward, no public exposure) before enabling.
Stop DIY: per-board isolation pinpoints a single hashboard whose reject% sits 3-5x the others, OR you've cleaned, repasted, downclocked, and rebuilt OC and reject% still climbs, OR a multi-miner same-model fleet shows the same reject% pattern simultaneously (points at a batch chip drift / firmware issue beyond DIY scope). Book a D-Central ASIC Repair slot.
What D-Central does at the bench: ICT560 / KD-class / CK-family / HS-class chip-family test fixtures isolate per-chip hashrate and bad-nonce rate, identify drifting chip positions, reflow the worst with preheat-plus-hot-air (preheat ~150 °C bottom side, top-side 310-330 °C for ~30 s) or replace from salvaged-grade inventory, then 24-hour burn-in at nameplate against a real pool with stale-share monitoring. Only ships back when reject% holds under 1% sustained.
Ship safely with a diagnostic note. Anti-static bag per hashboard if you can pull them, otherwise the whole miner well-padded. Double-box, ≥5 cm foam every side. Include a note with model, firmware version, current pool, mode setting, observed reject% history, and any ping/RTT logs you've captured. That note saves us 30-60 minutes of diagnostic time, which saves you money. Canada / US / international — we bench everything that ships.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
