Bitaxe – Pool Rejected Shares High Rate
Warning — Should be addressed soon
Symptoms
- AxeOS Rejected counter climbing; Rejected / (Accepted + Rejected) > 2% sustained 30+ min
- AxeOS log shows repeated `Share rejected: Above target`, `Job not found`, or `Stale share` lines
- `Best Difficulty` counter frozen or climbing much slower than hashrate would suggest
- Pool dashboard shows worker online but effective hashrate 10-30% below local AxeOS reading
- Reject spike appears immediately after `mining.set_difficulty` in log (especially downward diff change)
- Rejects correlate with WiFi drops or `wifi:` warning lines on 2.4 GHz-only Bitaxes
- Reject rate spikes at a specific time of day (neighbourhood 2.4 GHz congestion)
- Rejects started immediately after OTA firmware flash (regression suspect)
- NTP sync fails silently; AxeOS clock reads pre-2020 or future years
- On Hex / UltraHex / Gamma Turbo: one chip position contributes majority of rejects
- Vcore reads >30 mV below preset under load; VIN sags below 4.85 V (5 V boards) or 11.4 V (12 V boards)
- Stratum URL stored with trailing slash or `stratum+tcp://` prefix (causes parser fail on older firmware)
Step-by-Step Fix
Wait a full 30 minutes after first power-on. Do not adjust anything. A 5-10% reject rate in the first 10-30 minutes is normal vardiff overshoot (ESP-Miner Issue #212 and Solo Satoshi confirm this). If rejects settle under 1% by t=30, you are done. Panic-tuning at t=5 min is the #1 cause of operators chasing phantom problems.
Cold power-cycle for a full 10 seconds (unplug USB-C on single-chip Bitaxes, or the 12 V barrel/XT30 on Hex and Gamma Turbo). Plug back in. Clears stratum socket state and forces a fresh `mining.subscribe` handshake. Watch rejects for 20 minutes.
Revert preset to Default / Stock: AxeOS -> Settings -> Preset -> Default. No OC, no UV. Reboot. Watch 20 minutes. If rejects clear, tuning was past the silicon-lottery ceiling - rebuild slower in Step 11.
Check firmware version at AxeOS -> System. Cross-reference against ESP-Miner release notes. Known-bad versions: v2.0.7 (BM1397 stratum), v2.7.1 (Gamma temp), v2.8.0 (Gamma I2C race per Issue #1291), v2.11.0 (temp regression), v2.12.2 (Ultra selftest per Issue #1600), v2.13.x (set_difficulty fractional per Issue #1592), any v2.14.0-beta*. Flash latest stable via OTA or https://bitaxe.org/flash.
Try a different pool. Point the Bitaxe at a geographically close public stratum: public-pool.io:21496, solo.ckpool.org:3333, or stratum.solomining.tech:3333. If rejects clear on pool B but not pool A, the problem is pool-side vardiff or protocol mismatch, not your miner. Canadian miners on Singapore pools lose ~2% to latency.
Override router DNS to 1.1.1.1 or 8.8.8.8. Canadian ISPs (Bell, Rogers, Videotron) and many US ISPs intermittently fail to resolve stratum hostnames - fixes mystery 'cannot reach pool' and also fixes NTP sync failure at boot (see skot/ESP-Miner Issue #184).
Verify NTP clock via USB-C serial console at 115200 baud - filter for `sntp` lines. If clock reads pre-2020 or future years, strict pools reject shares on `nTime` validation. Fixing DNS (Step 6) usually resolves this; reboot after.
Move the Bitaxe within 3 m of the router. ESP32-S3 is 2.4 GHz only. Weak signal drops stratum packets and produces `Stale` / `Job not found` rejects that look identical to silicon issues. Lock router to channel 1, 6, or 11 manually - auto-channel hopping compounds the problem.
Swap the power supply with a known-good unit. For Supra/Ultra/Gamma use USB-C PD >=5 V/3 A from a reputable brand (Anker, Apple 30 W, or the D-Central Bitaxe PSU). For Gamma Turbo / Hex use quality 12 V/5 A+ barrel or XT30. Cheap USB-C chargers sag to 4.6 V under load - the #1 silent cause of nonce corruption in D-Central's ticket queue.
Measure VIN and Vcore under load with a multimeter. Probe VIN at USB-C/XT30/barrel input: expect >=4.85 V (5 V boards) or >=11.4 V (12 V boards). Probe Vcore on chip pads (TPS546 output): expect within +/-30 mV of AxeOS preset (typically 1.15 V Gamma, 1.20 V Supra/Ultra). Sag = PSU tired, cable too thin, or TPS546 drifting.
Rebuild overclock from stock in 25 MHz steps. Wait 20 minutes between steps. Stop at the last step before rejects cross 1.5%. That is this chip's silicon-lottery ceiling - varies +/-100 MHz between two identical Gammas bought the same day. Silicon lottery is real; you cannot tune your way past it.
Tune Vcore down in 10 mV steps. 20 minute stability window each. Stop before rejects climb. Typical safe undervolts: 1.12 V Gamma, 1.17 V Supra, 1.15 V Ultra - but verify per chip. Below chip-specific threshold, nonces corrupt.
Replace thermal paste with Arctic MX-6 or Thermal Grizzly Kryonaut if rejects correlate with temp climb. Bitaxe paste dries after ~12 months of continuous operation. Uniform thin layer. Expect 5-8 C temp drop. Pair with a proper heatsink - D-Central manufactured the first Bitaxe heatsinks on the market.
Use a wired Ethernet connection if your case / adapter supports it (some D-Central cases do). Eliminates WiFi jitter entirely. On Hex, use the dedicated Ethernet header if your board rev has one.
Switch stratum endpoint between SSL (port 443) and plain TCP (3333 / 21496). Some Bitaxe firmware versions have TLS edge cases with specific pools. Public-Pool, CKPool, and Ocean all offer both. Flip and observe 20 minutes.
Flash via USB-C web flasher at https://bitaxe.org/flash when OTA is broken, NVS is corrupt, or you need a clean factory image. Use Chrome or Edge (WebSerial). Pick the exact board variant - Ultra 202 vs 204 vs 205 vs 207, Gamma 601 vs 602, Hex 303 vs 304 - and match the firmware .bin precisely. Wrong .bin bricks the device (BM1366 vs BM1370 firmware mismatch is a common Bitaxe death).
Reflow the failing ASIC on multichip Bitaxes (Hex, UltraHex, Gamma Turbo) if per-chip isolation points at one position. Preheat 150 C, hot-air 310-330 C for ~25 seconds on a BM1366/BM1370 BGA. Flux generously. Re-seat heatsink with fresh paste. Bitaxe boards are the low-risk practice ground before touching an S19 hashboard.
Swap the TPS546 regulator on Gamma 601/602 if Vcore cannot hold under load. Hot-air rework, fresh TPS546B25xx chip, recalibrate via AxeOS. This is also the fix for Power Fault Detected (Issue #1188) when it correlates with reject spikes.
Roll firmware backward to a known-good version if rejects started exactly after OTA and current version is on the regression list. ESP-Miner release archive: https://github.com/bitaxeorg/ESP-Miner/releases. Flash via USB-C web flasher - the safest recovery path.
Ship to D-Central when: per-chip reject isolation points at a chip that reflow did not fix, TPS546 replacement did not restore Vcore, wrong firmware .bin bricked the device and web flasher recovery failed, or physical damage is visible. D-Central pioneered the Bitaxe Mesh Stand and Hex heatsink; we stock every variant and every spare part. Book a repair slot at https://d-central.tech/services/asic-repair/.
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.
