Bitaxe – Stale Share Flood / High Reject Rate
Pool returns repeated {"error": [21, "Job not found", null]} responses to mining.submit; AxeOS reject (R) counter climbs faster than accepted (A); pool-side dashboard shows effective hashrate 30-90% below local hashrate. Driven by WAN latency, ESP32-S3 task starvation under aggressive tune, DNS TTL anomalies / anycast flipping, or stratum extranonce extension drift mid-session.
Warning — Should be addressed soon
Symptoms
- AxeOS dashboard shows accepted shares (A) climbing slowly while rejected (R) climb faster, with reject rate above 2% sustained for 30+ minutes
- AxeOS share-log feed contains lines matching share rejected: stale, Job not found, H: stale, or JSON-RPC error code 21
- USB-C serial console at 115200 baud shows pool responses {"error": [21, "Job not found", null]} repeating every few minutes
- Local hashrate tile reads healthy (within 5% of variant nameplate) but pool-side effective hashrate is 30-90% lower than what AxeOS reports
- ping from a laptop on the same LAN to the pool's stratum host returns >150 ms RTT, packet loss, or asymmetric forward/return paths
- traceroute to the pool shows hops crossing a continent that isn't yours or the pool's (geographic trombone)
- Stale-rate spikes correlate with specific times of day — late evening on residential ISPs, business hours on commercial connections
- Recent change preceded the flood: switched ISPs, added a VPN, moved the Bitaxe to WiFi, swapped pool URL, OTA-updated AxeOS, or pushed a new tune
- Two Bitaxes on the same LAN — one on pool A reports clean accepted shares, the other on pool B floods stales (pool-side variable confirmed)
- AxeOS log shows mining.notify with clean_jobs: true followed within one second by mining.submit returning the stale rejection — classic deadline race
- Bitaxe is pointed at a hostname that DNS-resolves to multiple IPs (anycast geo-routed) and the resolver flips between IPs mid-session
- Cold power-cycle clears the symptom for 5-30 minutes, then it returns — slow-creep state issue (DNS cache age, TCP retransmit backoff, or extranonce drift)
- Tune profile is aggressive (Gamma above ~1.4 TH/s at marginal core voltage, Ultra above ~0.55 TH/s) — ESP32 plausibly task-starved on stratum-handler thread
- Solo mining on solo.ckpool.org and the stale counter is meaningful — every stale on solo is a chunk of already-thin lottery odds vanishing
Step-by-Step Fix
Cold power-cycle the Bitaxe for 10 seconds. Unplug USB-C (or the 12V XT30 / barrel input on Hex / GT) for a full 10 seconds. Plug back in. Soft reboot via the dashboard isn't enough — it preserves the stratum task's TCP state and replays the broken behaviour. A hard power-cycle resets the ESP32-S3 stratum state machine cleanly. This alone clears 20-30% of stale floods caused by transient session drift.
Switch to the closest regional pool endpoint. AxeOS → Settings → Stratum. Replace URL with the closest published endpoint: public-pool.io:21496 (US-East), mine.ocean.xyz:3334 (anycast), stratum.braiins.com:3333, or pool.d-central.tech for Canadian operators. Save settings, then cold power-cycle for 10 seconds. Watch for 30 minutes — stale rate should fall under 1% if regional latency was the variable.
Wire the Bitaxe to Ethernet, not WiFi. Bitaxe variants with Ethernet support (Hex, Gamma in some kits) almost always run cleaner on wired vs WiFi. WiFi adds 20-80 ms of jitter and re-transmissions, especially on busy 2.4 GHz channels. Run a CAT5e/CAT6 cable to the router, switch AxeOS network mode to Ethernet, save, cold power-cycle. Stales tied to WiFi jitter clear immediately.
Verify the BTC address you pasted is a valid mainnet payout address. Pools are strict. Public-Pool wants bc1q…, 1…, or 3… plus .workername. Lightning addresses pasted by mistake (lnbc… format) sometimes pass mining.subscribe, pass mining.authorize, then silently break at first share submission. The dashboard symptom looks identical to a stale flood. Cross-check the address character-by-character against the pool's getting-started page.
Check pool dashboard for accepted shares vs effective hashrate. Visit your pool's worker page in a browser. Compare its effective hashrate against AxeOS's local hashrate tile. If pool-side is 30-90% lower, stales are being silently absorbed and the pool's number is right. This confirms you're on the correct page rather than chasing a dashboard-display bug.
ping and traceroute the pool from a laptop on the same LAN. ping -c 60 <pool-host> for 60 packets; record min/avg/max RTT and packet loss. Then traceroute (or tracert on Windows). Above 150 ms avg RTT is a network-side stale-share generator. Above 250 ms avg RTT plus any packet loss is a near-guarantee of a stale flood. Switch pools, switch ISPs (mobile hotspot test for 30 minutes is a good A/B), or escalate to a stratum proxy in Tier 3.
Override pool hostname with a fixed IP in AxeOS. Resolve with dig +short <host> from a laptop. Replace the hostname in AxeOS → Settings → Stratum with the literal IP (e.g., 203.0.113.42:3333 instead of pool.example.com:3333). Save and cold power-cycle. Eliminates anycast / geo-DNS flipping mid-session as a variable. Re-resolve every few weeks; pools rotate IPs occasionally.
Soft-tune the Bitaxe to factory defaults. AxeOS → Settings → Tune → Reset to default. Save, cold power-cycle. Run 30 minutes. If stale rate drops, your previous tune was task-starving the ESP32 stratum handler. Re-tune in 10 MHz / 25 mV steps with a 10-minute stability window between each step. Stop at the step before the stale rate climbs above 1%. That's this Bitaxe's network-protocol-aware ceiling — per-unit, the ESP32-side margin varies with silicon and ambient.
Capture USB-C serial console at 115200 baud. Plug a data-capable USB-C cable (not charge-only). Open serial terminal — screen on macOS/Linux, PuTTY on Windows, or Chrome WebSerial in-browser at https://bitaxe.org/flash. Filter for stratum and notify. Confirm the failure mode: stratum task starvation (gaps between mining.notify arrivals and processing) vs WAN deadline race (clean processing but submission lands >500 ms after notify) vs extranonce drift. Save 5-minute capture.
Disable any VPN, stratum proxy, or middlebox in the path. If the Bitaxe traffic crosses a VPN or stratum-proxy on your LAN, bypass for a 30-minute test. VPNs add 30-100 ms RTT minimum; abandoned stratum proxies sometimes mangle JSON-RPC framing. Bypass = Bitaxe pointed directly at the pool's hostname over your normal upstream. If stales clear, the middlebox was the variable.
Wireshark the stratum exchange. From a laptop on the same LAN, run Wireshark with filter tcp.port == 21496 and ip.addr == <bitaxe-ip>. Capture 10 minutes of mining.notify, mining.submit, and pool responses. Look at timestamps: how long between mining.notify arriving and the next mining.submit going out? How long between mining.submit and the pool's accept/reject? If submit-to-response is consistently above 300 ms, you have a confirmed WAN deadline race. If notify-to-submit shows multi-second gaps, you have ESP32 task starvation.
Stand up a stratum proxy on a low-latency VPS in the pool's region. Spin up a $5/month VPS (Hetzner, OVH, Vultr) in the same datacenter region as the pool. Install a current-gen stratum proxy (braiins-os proxy mode, cgminer-stratum-proxy, or a small Go-based proxy). Point the Bitaxe at the VPS; point the VPS at the upstream pool. The slow leg becomes Bitaxe-to-VPS; the fast leg is VPS-to-pool. Net effect on a 300 ms original path is often a ~100 ms improvement and a measurable stale-rate drop.
Roll AxeOS firmware back to last-known-good. AxeOS → System → OTA Update. Note current version. Download the last-known-good .bin from github.com/bitaxeorg/ESP-Miner/releases matching your exact board revision (Ultra 205/207, Gamma 601/602, Hex 303/304 — printed on PCB silkscreen). Web-flash via Chrome at https://bitaxe.org/flash. Watch boot log on serial. Stale-handler regressions are documented on the issue tracker; check before flashing. Wrong .bin for wrong board bricks the device.
Build ESP-Miner from source with verbose stratum logging. Clone bitaxeorg/ESP-Miner (or skot/ESP-Miner for the original tree). In main/stratum_api.c, add ESP_LOGI traces around stratum_api_handle_notify, stratum_api_submit_share, and stratum_api_handle_set_extranonce. Build with ESP-IDF v5.x, flash via USB-C. Reproduce the flood; the extra log lines pinpoint exactly which handler is starving or mishandling. Submit fixes upstream — the Bitaxe ecosystem grew because plebs sent patches back.
Patch the stratum task priority in FreeRTOS. If you've confirmed task starvation under tune, the surgical fix is to bump the stratum task's priority offset above the mining task in main/main.c (or wherever AxeOS spawns the stratum task). Build, flash, re-test. Risk: bumping too high can starve the mining task; do this in increments and watch local hashrate carefully. Submit the patch upstream if it works — exactly the Mining-Hacker contribution that keeps ESP-Miner ahead of stock firmware on commercial hardware.
Stop DIY and ship to D-Central when (a) factory-flashed Bitaxe pointed at three modern public pools all show stale floods within 30 minutes per pool over a known-good wired LAN with sub-50 ms RTT, (b) Wireshark shows clean network exchange but AxeOS processes mining.notify >500 ms late on stock tune, (c) failure persists across factory flash + clean URL/port + DNS IP override + LAN swap + cable swap + PSU swap + tune-to-factory, or (d) physical damage is visible (scorched USB-C port, cracked PCB, bulged cap, blown fuse on VIN).
D-Central bench process for a stale-flood Bitaxe: test fixture with known-good public-pool.io:21496 connection over clean wired LAN with 1.1.1.1 DNS, serial log capture at 115200 baud, Wireshark on bench LAN, ESP-Miner factory flash of current stable matched to exact board revision. Replay your symptom set. If the bench rig reproduces, ESP32-S3 itself, NVS partition, or PCB-level signal integrity is suspect — chip-swap or board-swap from D-Central's Bitaxe inventory. D-Central pioneered the Bitaxe ecosystem and runs bench rigs tuned for stratum-path diagnostics.
Ship safely. Pack the Bitaxe in an anti-static bag. Double-box with at least 3 cm of foam on every side. Include a note with: observed stale rate, pool URL + port + SSL setting that triggered the symptom, AxeOS firmware version, board revision (printed on PCB), tune profile, and saved serial log if captured. The note saves D-Central's bench tech 30 minutes of preliminary diagnostics, which saves your repair cost. Ship to address listed on the D-Central ASIC Repair page.
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.