AxeOS Solo Mode Toggle Missing After Firmware Update

Confirm the firmware version against the upstream changelog. Open AxeOS → System → Version. Read the full version string verbatim (including any -rcN / -betaN suffix). Open the bitaxeorg/ESP-Miner releases page in a second tab. Find your version. Scan release notes for 'solo,' 'pool,' or 'settings' mentions. If your version is from a fork (shufps/, skot/, vendor-specific), check that fork's releases page. Documenting the exact version is step zero of any debugging conversation.

Configure solo mining manually in the standard four stratum fields. AxeOS → Settings → Pool / Stratum. Type solo.ckpool.org into Primary URL (no stratum+tcp:// prefix, no trailing slash). Type 3333 into Primary Port. Set SSL = OFF. Type your on-chain BTC address followed by a worker name into User — bc1qxxxxxxxxxx.bitaxe-gamma-solo is a fine pattern. Type x into Password. Save. This is the underlying configuration the toggle used to wrap; the toggle's absence doesn't change what solo mining requires.

Cold-power-cycle for 10 seconds after Save. Unplug the USB-C cable (or XT30 / barrel input on Hex / GT) for ten full seconds. A soft reboot through the AxeOS UI is not always sufficient — the cold cycle is. Plug back in. Watch the AxeOS dashboard for an Accepted count to start ticking within 30-90 seconds. The first share confirms the stratum handshake is alive.

Verify on the pool's worker view, not the AxeOS UI. Open https://solo.ckpool.org/users/<your-bc1q-address> (substitute your actual address). If the page shows your Bitaxe as a registered worker with non-zero hashrate1m and recent lastshare timestamp, you are unambiguously solo mining. The pool's accounting is the source of truth — the AxeOS UI's 'Solo Mode' badge was a convenience indicator, not a status signal.

Rename your worker for clarity. If you operate multiple Bitaxes — some pooled, some solo — the worker suffix is your bookkeeping. .bitaxe-gamma-solo, .bitaxe-hex-solo, .bitaxe-ultra-pool keeps the pool's worker view legible. AxeOS's missing toggle is no longer doing this labelling for you, so be deliberate in the User field.

Set the Fallback stratum to a different solo pool for redundancy. AxeOS → Settings → Stratum → scroll to Fallback. Configure Fallback URL = pool.ckpool.org or web.public-pool.io configured for solo, Port appropriate to that pool, User = <your bc1q address>.fallback-solo, Password = x. Save. If the primary solo pool's stratum endpoint hiccups, the Bitaxe rotates to fallback. Pairing primary and fallback across two solo pools is also a quiet decentralization win.

Document your solo configuration externally. Since the toggle is gone, the configuration is purely textual: pool URL, port, BTC address, worker suffix. Save it in a password manager or notes app. After a future firmware update — or if you have to factory-flash — you can reproduce a known-good solo setup in 60 seconds without scratching your head over which pool you used last time.

Take a screenshot of the working configuration once shares are accepted. Capture AxeOS → Pool / Stratum settings (with the configured values) and the pool's worker page (showing your Bitaxe registered). Save both. This is your evidence the device is solo-mining despite the missing UI badge.

Use the AxeOS REST API to set the four stratum fields atomically. Open a terminal and run: curl -X POST http://<bitaxe-ip>/api/system -H 'Content-Type: application/json' -d '{"stratumURL":"solo.ckpool.org","stratumPort":3333,"stratumUser":"bc1q...your-address.bitaxe-solo","stratumPassword":"x"}'. Then trigger reboot: curl -X POST http://<bitaxe-ip>/api/system/restart. This is the toggle's mechanical equivalent — clean atomic save plus restart in two API calls, scriptable across a fleet.

Inspect the AxeOS settings page DOM for hidden solo-related fields. In Chrome / Firefox, open AxeOS → Settings → Pool. Right-click → Inspect Element. In DevTools Elements panel, Ctrl+F search for solo, is_solo, mode, or useSolo. If you find a hidden input element, the toggle exists in the bundle but is conditionally hidden — you can manually flip the checkbox state via the JavaScript console and re-Save to test. Ugly, but diagnostic.

Read the AxeOS source bundle to find the toggle's render condition. Save the AxeOS settings page HTML (Ctrl+S → 'Webpage, Complete'). Open static/js/main.<hash>.js in a text editor. Search for solo. The render condition will be a JSX expression like {settings.is_solo && <Toggle...>} or {showSoloMode ? ... : null}. Once you know the condition, you know what's preventing render — usually a stale or missing NVS field. This is the fastest path from 'toggle is gone' to 'I understand why.'

Run a fresh factory flash via the USB-C web flasher. Plug a data-capable USB-C cable. Open https://bitaxe.org/flash in Chrome or Edge (WebSerial required). Click Connect, select your exact board revision (Supra 401, Ultra 205/207, Gamma 601/602, Hex 303/304, GT 701/702 — silkscreened on the PCB). Pick the factory .bin, click Flash. NVS is wiped; the toggle's render condition resets to whatever the build's default is. If the toggle was hidden by stale NVS state, this brings it back.

Pin to a specific firmware version that you know exposes the toggle. If the toggle is non-negotiable for your workflow — operators running Bitaxe demo rigs at meetups, training environments, personal preference — flash a known-good prior version and stay there. AxeOS firmware versions don't auto-update; you control when the device updates. Document the version, archive the .bin file locally.

Write a tiny status script that reads /api/system/info and reports solo-vs-pool status. Sample: curl -s http://<bitaxe-ip>/api/system/info | jq '{url:.stratumURL, port:.stratumPort, user:.stratumUser}'. If stratumURL matches a known solo pool (solo.ckpool.org, pool.ckpool.org, configured Public-Pool solo endpoint), you're solo mining. Run the script across a fleet, or set it as a Home-Assistant / Node-RED sensor for at-a-glance status.

Clone bitaxeorg/ESP-Miner and grep the source for the solo toggle's history. git clone https://github.com/bitaxeorg/ESP-Miner.git, then git log -S 'is_solo' or git log -S 'soloMode' to find the commits that introduced or removed the toggle. The commit messages and diffs are the authoritative answer to 'when did this change and why.' File a documentation issue on the project if the change isn't in the release notes.

Re-introduce the toggle in your local build. If the toggle was removed but you want it back, fork bitaxeorg/ESP-Miner, find the commit that removed it, revert that change, build with ESP-IDF v5.1+, flash via USB-C web flasher (point the flasher at your local .bin). You're now running a custom AxeOS that exposes the toggle. Because the firmware is open-source under GPL, this is squarely within the spirit of the project — just understand you're maintaining your own fork now.

Submit a PR that makes the toggle render conditional on a user-visible setting. The cleanest community fix: rather than removing the toggle outright, hide it behind an 'Advanced' expander or a 'UI Mode: Simple / Advanced' preference. Open a PR against bitaxeorg/ESP-Miner with the change. Mining Hacker ecosystem norms: bugs surface in public, fixes get reviewed in public, and the firmware that runs your $150 lottery ticket gets better one PR at a time.

Build a custom AxeOS UI bundle without modifying the firmware logic. If you're a frontend developer, the AxeOS web UI is a React app shipped as a static bundle. Clone the UI source, modify the settings page to always render the solo toggle regardless of NVS state, build, and replace the bundle in the firmware's static assets. This is a UI-only change — you don't need to recompile the ESP-IDF backend. Document the patch and share it.

Stop DIY and ship the device when (a) factory-flashing the latest stable upstream .bin for your exact board revision via https://bitaxe.org/flash does not restore expected behaviour and the device cannot be configured to solo-mine via the REST API either, (b) the AxeOS web UI itself is unreachable across multiple flashes, or (c) physical damage is suspected (scorched USB-C, cracked PCB near the ESP32-S3, bulged cap, scorching near TPS546). D-Central pioneered the Bitaxe ecosystem — built the original Bitaxe Mesh Stand, developed the first heatsinks for Bitaxe and Bitaxe Hex, stocks every variant since launch — and our bench keeps Bitaxe diagnostic and reflashing rigs ready. Book at https://d-central.tech/services/asic-repair/.