Stale Shares on Bitmern Solo (Diagnose & Fix)
If Bitmern Solo shows stale or late shares while the worker still exists, run an ordered triage: clock skew / NTP on the miner or LAN, wrong VarDiff or port…
Shares that land late — or get labeled stale — are not the same as a high-reject storm, a vanishing worker row, or a hashrate card that simply fell. Late work usually means the board finished a job after the pool had already moved on, or the path between miner and stratum added enough delay that the result arrived past usefulness.
If Bitmern Solo shows stale or late shares while the worker still exists, run an ordered triage: clock skew / NTP on the miner or LAN, wrong VarDiff or port on the BTC easy-start path, reconnect flaps, Wi-Fi lag, then dashboard vs board mismatch. For BTC home/Bitaxe, easy-start stays :3132 (never treat :3102 as default). Username WALLET.worker, password x. This post does not invent a product stale-share SLA timer.
This is the stale/late-work checklist. High rejects with climbing accepts: rejected shares fix. Row still there but rate fell: hashrate drop fix. Row gone: worker offline fix. Accepts never started: Bitaxe not submitting shares. Field wiring: AxeOS setup. Ports: VarDiff stratum ports.
Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Fee context stays light here — the job is clearing late work so accepts stay useful on the matching coin tab.
Stale ≠ rejected ≠ hashrate drop ≠ offline
Four patterns get mixed up:
- Rejected shares — work arrived but failed validation (wrong job, bad difficulty, auth issues). That is the rejected shares path.
- Hashrate drop / stall — worker row still there; rate soft or frozen vs the board. That is the hashrate drop path.
- Worker offline — row missing or marked offline. That is the worker offline path.
- Stale / late shares — results arrive after the job window; firmware may still look “busy” while the account shows stale counts or soft accepts. That is this post.
Do not invent a Bitmern Solo product default that “shares older than N seconds are always stale.” Read the live Workers / Shares view, your miner UI, and the ordered checklist below.
What usually makes shares land late
Common causes on Bitaxe-class and small ASIC desks:
- Clock skew / NTP — miner or LAN gateway clock drifted; job timing and share timestamps disagree with the pool.
- Wrong VarDiff or port — home BTC pointed at a non-easy port (or leftover
:3102habit) so difficulty and job cadence fight the board. - Reconnect flaps — stratum connects, drops, reconnects; in-flight work expires before the next stable session.
- Wi-Fi lag / packet loss — share upload delayed enough that the pool already advanced.
- Dashboard vs board mismatch — miner UI shows accepts; account cards lag one refresh — or the reverse, so you chase “stale” that already cleared.
- Failover / secondary pool fighting — a backup slot steals the session mid-job and leaves half-finished work on Bitmern Solo.
Separate these from a row that is simply gone (offline) and from a pure reject storm (rejected shares).
Ordered fix checklist
Run top to bottom. Stop when stale counts calm and fresh accepts move on the matching coin tab while the board hashes.
1. Confirm you are not in offline, no-shares, or pure rejects
Symptom: Worker row missing/offline, accepts never landed, or rejects dominate without a late-work story.
Action: Leave this article. Use worker offline, no-shares, or rejected shares. Stale triage assumes the worker maps and you are debugging late arrival, not a missing row or a pure validation storm.
2. Open the matching coin tab
Symptom: One coin tab looks “stale” while another coin is fine — or you assume the whole account is late.
Fix: Open the same coin the miner is pointed at. A BTC-pointed board will not populate LTC share cards. Coin flips: switch coins.
3. Check clock skew / NTP before rewriting stratum
Symptom: Firmware clocks look wrong, share timestamps jump, or the board and your phone disagree on time by minutes.
Fix: Sync time on the miner (AxeOS / ASIC time settings) and on the LAN gateway if it serves NTP. A large skew makes “late” look like a pool problem when the desk clock is the culprit. Do not invent a Bitmern Solo product SLA that “skew under N ms is guaranteed safe.”
4. Compare board UI vs dashboard — lag vs real late work
Symptom: AxeOS shows climbing accepts; Bitmern Solo stale/share cards look behind — or the reverse.
Fix: Note both readings at the same moment. If the board already recovered and shares climb on the next refresh, wait one account cycle before rewriting known-good fields. If the board still shows reconnect counters climbing or job timeouts, treat path latency and stratum next.
5. Lock BTC easy-start :3132 (never treat :3102 as default)
Symptom: Home Bitaxe on BTC with late shares after a port experiment, or flaps after leaving the easy path.
Fix: Point BTC at:
stratum+tcp://btc.bitmernsolo.com:3132
Username: YOUR_WALLET.worker1 (or your preferred worker suffix after the dot). Password: exactly x.
Never treat :3102 as the Bitaxe / home default. Other VarDiff ports exist once the easy path is stable — see VarDiff ports. Jumping ports before :3132 is clean usually adds late work instead of removing it.
6. Username and password shape
Required:
WALLET.worker
password: x
Traps that scramble attribution: missing dot, spaces, underscore instead of the dot, wrong wallet prefix vs the registered receive address, password not exactly x, or watching the wrong suffix while another worker label is the one receiving shares.
Field wiring: AxeOS setup. Naming depth: worker naming.
7. Kill reconnect flaps and bad failover slots
Symptom: Firmware reconnect counter climbing; secondary pool stealing the session; shares land in bursts then go stale.
Fix: Put Bitmern Solo on the primary (or only) pool slot. Clear or disable failover slots that point at a different host while you diagnose. Host must match the coin (btc.bitmernsolo.com for BTC). Save and apply so the board is not still bound to a previous solo pool or a shared-pool URL. Deeper reconnect work: reconnect loops fix (when live).
8. Stabilize Wi-Fi / LAN latency
Symptom: RSSI weak, packet loss in firmware logs, or share upload delayed only when the AP is busy.
Fix: Move closer, use a cleaner channel, prefer Ethernet where the board allows it, and stop streaming that saturates the same radio. Latency that makes shares late is a path problem — not a reason to invent a Bitmern Solo “max share age” product default.
9. Prove it on the Bitmern Solo dashboard
Open the matching coin tab. Confirm:
- Worker row still present under the expected label
- Fresh accepts moving (stale counts calming, not dominating)
- Hashrate reading believable while the board hashes
- Current Effort leaving a stuck empty reading when attribution works
Card reading stays in the dashboard guide. Here you only verify late work cleared on the account, not only on the miner UI.
When hashrate-drop or rejects are the real story
If the worker row is fine but the rate fell without a late-share story, switch to hashrate drop. If rejects climb while accepts still move, use rejected shares. Stale triage is for late arrival — not every red number on the Shares card.
What this post will not invent
- No product default “shares older than N seconds are always stale”
- No confirmation-delay SLA for when the Shares card must match firmware
- No luck formulas, dollar EV, or find-time promises from a stale window
- No claim that
:3102is the home Bitaxe default - No competitor fee comparisons
Fee reminder only if you need it: flat 1% on finds; you keep 99%. Stale shares are an ops signal, not a fee.
Soft next step
Sync time, lock BTC to :3132 with WALLET.worker / x, kill failover flaps, then confirm fresh accepts on the matching coin tab before you chase deeper hardware swaps.
Start mining
Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.
FAQ
Are stale shares the same as rejected shares?
No. Rejects failed validation; stale/late work arrived after the useful job window. Use rejected shares when rejects dominate; use this post when lateness is the story.
What BTC port should a home Bitaxe use first?
:3132 on btc.bitmernsolo.com. Never treat :3102 as the Bitaxe / home default. See VarDiff ports.
What username and password does Bitmern Solo expect?
Username WALLET.worker (wallet prefix must match the registered receive wallet for that coin). Password x.
Can clock skew alone cause late shares?
Yes. Sync miner and LAN time before you rewrite a known-good stratum string. This post does not invent a product skew SLA.
How do I tell dashboard lag from real late work?
Compare miner UI and Bitmern Solo at the same moment. Board already healthy and accepts climb on the next refresh → wait one cycle. Board still flapping or timing out jobs → fix path and stratum next.
Where does worker offline fit?
If the row is gone or marked offline, leave this article for the worker offline checklist.
Where do I confirm the fix on Bitmern Solo?
Matching coin tab → worker row → fresh accepts (stale calming) → believable hashrate. Guide: dashboard workers / shares / effort.
