A maintained Bitcoin Mining with Bitaxe reference

Bitaxe Models and Firmware—Know What You Have Before You Update

Use the hardware project, board version and firmware release state together. A familiar model name or a larger version number is not enough.

The short answer

Bitaxe is a family of open-source Bitcoin miners, not one fixed product. Before choosing firmware, identify the model family, exact board version, ASIC model and count, and installed ESP-Miner/AxeOS version.

Then use the hardware repository, current ESP-Miner release page and the exact factory image or supported update path for that board. Do not choose a file only because its version number is highest.

Current ESP-Miner release status

Verified October 5, 2026.

v2.15.3 is the current latest stable ESP-Miner release. It was published September 20, 2026.
The older v2.15.2 release remains labelled pre-release on GitHub.
A newer experimental build named checksum-test-0 is also labelled pre-release. It is not GitHub’s Latest release and should not be treated as the ordinary stable update.
BM1372/BM1373 driver support and Naja Duo/Gamma Hex display support first appeared in the v2.15.2 change list. v2.15.3 follows that work and adds a low-frequency-warning fix based on device presets.
Since v2.15.0, AxeOS is embedded in the main esp-miner.bin; a separate www.bin is no longer required for a normal update.

Release labels can change. Check the official ESP-Miner releases page immediately before updating. A stable firmware release also does not turn prototype hardware into a production-ready design.

Core Bitaxe hardware and source map

This table maps designs to their primary source repositories. It does not certify a seller, assembly, firmware image or performance result.

Design or family	ASIC configuration	Primary source	Firmware and maturity note
Bitaxe Max (10x)	1 × BM1397	bitaxeorg/bitaxeMax	Established source; choose the exact board image.
Bitaxe Ultra (20x)	1 × BM1366	bitaxeorg/bitaxeUltra	Established source; board revision matters.
Bitaxe Ultra Hex (30x)	6 × BM1366	bitaxeorg/ultraHex	Confirm current multi-chip support and exact image.
Bitaxe Supra (40x)	1 × BM1368	bitaxeorg/bitaxeSupra	Established source; board revision matters.
Bitaxe Gamma (60x)	1 × BM1370	bitaxeorg/bitaxeGamma	Established source; board revision matters.
Bitaxe Gamma Duo (65x)	2 × BM1370XP	650-duo branch	Source-listed design; verify the current release asset.
Bitaxe Supra Hex (70x)	6 × BM1368	TinyChipHub/supraHex	Use the firmware branch named by the hardware project.
Bitaxe Gamma Hex (70x)	6 × BM1370	TinyChipHub/bitaxeHex-TCH	The OSMU list maps this family to ESP-Miner-TCH.
Bitaxe GT / Gamma Turbo (80x)	2 × BM1370	bitaxeorg/BitaxeGT	Confirm the board-specific ESP-Miner asset.
Bitaxe Gamma Hex (130x)	6 × BM1370	bitaxeorg/BitaxeGammaHex	Confirm the board-specific ESP-Miner asset.
Naja Duo	2 × BM1373	bitaxeorg/naja-duo	Prototype. The upstream README still calls the design untested; verify exact hardware instructions and release assets.

The OSMU-maintained FOSS miner list is the best compact upstream cross-reference found for established designs. As of this review it includes the Bitaxe families through the two Gamma Hex entries but does not list Naja Duo. Naja appears here only because its own bitaxeorg repository and ESP-Miner history provide direct evidence, and its prototype status is stated explicitly.

Naja Duo maturity note

The Naja Duo repository describes a dual-BM1373 open-source miner and says the BM1373 is suspected to be the ASIC used in the Antminer S23 series. The same README warns that the design remains an untested prototype. Treat both as upstream project statements, not independently established production specifications. Do not build, buy or flash a Naja Duo solely because ESP-Miner contains BM1373 support.

What the model number does—and does not—tell you

Family numbers such as 20x, 40x and 60x identify broad hardware generations. The exact board version still matters because firmware releases can provide different factory images within the same family.

Do not flash a “Gamma” image merely because the device uses a BM1370.
Do not assume all six-chip designs use the same firmware branch.
Do not substitute a community fork for the project named by the hardware repository without understanding why.
Do not treat a seller’s product name as a reliable board-version identifier.

If the dashboard is available, record its reported board, family, ASIC, ASIC count and firmware version. Otherwise, inspect the board markings and exact seller or project documentation before selecting a recovery image.

Stable, pre-release and source builds

Latest stable release

GitHub’s Latest marker is the clearest project-level signal for the release intended for ordinary use. It does not guarantee identical behaviour on every board. Read the release notes and confirm that the required factory asset exists.

Pre-release

Pre-releases can be appropriate for new-hardware support, testing and early fixes. They can also contain known or undiscovered problems. Record why the pre-release is needed and preserve a rollback path.

Main-branch or custom build

A source build is a development artefact, not a general recommendation. Record the commit, build environment, board configuration and test result. “Current main” is not a reproducible version description.

A safe update record

Record these details before changing firmware. Do not include pool passwords or other secrets in anything you share.

Field	Record before update
Device/model and board version
ASIC model and count
Current firmware
Target firmware and release status
Target filename and published checksum
Pool configuration backed up	Yes / No
Current frequency and core voltage
Baseline observation window, hashrate, power, temperature and fan state
Recovery method confirmed	Yes / No
Reason for update

Use a checksum published with the release asset when available. Keep the previous image or recovery route until the miner has operated normally long enough for a useful comparison.

Update decision sequence

Identify the board

Confirm the family, exact board version, ASIC and chip count.

Read the hardware source

Follow the repository linked for that design, including its errata and recovery guidance.

Read the release notes

Check whether the target is Latest, pre-release or an untagged source build.

Confirm the asset

Match the factory image or update file to the exact board version.

Preserve configuration

Record pool, network, frequency, voltage and custom cooling details without sharing secrets.

Preserve a recovery path

Know how to reach recovery or use the official web flasher before beginning.

Change one layer

Do not combine firmware, power, cooling and overclocking changes.

Verify against the baseline

Compare stability, accepted shares, temperature, fan behaviour, power and errors over a stated observation window.

Recovery and factory flashing

ESP-Miner documents a local recovery page at http://<device-address>/recovery when the normal dashboard is unavailable. The official Bitaxe Web Flasher is intended for flashing a factory file by USB after selecting the model and board version.

A factory flash can overwrite configuration. Treat recovery as a planned procedure, not something to discover after an update fails.

Comparing performance responsibly

A model name alone does not produce a reproducible performance claim. Include the exact board and ASIC count, firmware version and channel, frequency and voltage, power supply and measurement method, cooling and ambient temperature, pool endpoint, accepted/rejected share context, observation duration, and whether the result was a brief peak or sustained average.

Keep three categories separate:

Project fact—for example, the ASIC configuration documented by the hardware repository.
Release fact—for example, a driver or interface change in official release notes.
Observed result—a measurement from one device under stated conditions.

This distinction makes technical reporting easier to verify and safer to cite.

Source hierarchy and primary references

For model and firmware claims, prefer the hardware repository, tagged ESP-Miner releases, the OSMU FOSS miner list, relevant upstream issues or pull requests for work in progress, vendor documentation for a vendor’s own assembly, and finally community reports clearly labelled as observations.

Revision history

Reviewed	Change	Primary source
2026-09-19	Initial model map; recorded v2.15.1 as Latest and v2.15.2 as pre-release.	ESP-Miner releases; OSMU list; hardware repositories.
2026-10-02	Updated Latest to v2.15.3; retained v2.15.2’s pre-release label; clarified Naja Duo’s untested-prototype state and absence from the OSMU list.	ESP-Miner releases; bitaxeorg/naja-duo; OSMU list.
2026-10-04	Reverified v2.15.3 as GitHub’s Latest stable release and identified the newer checksum-test-0 build as a pre-release test artifact; rechecked the Naja Duo warning, OSMU list and Web Flasher.	ESP-Miner releases; bitaxeorg/naja-duo; OSMU list; Bitaxe Web Flasher.
2026-10-05	Publication-day recheck confirmed the same release labels and hardware-source map: v2.15.3 remains Latest, checksum-test-0 and v2.15.2 remain pre-releases, and Naja Duo remains an untested prototype absent from the OSMU list.	ESP-Miner releases; bitaxeorg/naja-duo; OSMU list; Bitaxe Web Flasher.

Continue with the book and maintained updates

Bitcoin Mining with Bitaxe explains setup, configuration, safe operation and troubleshooting. The update hub records fast-changing community developments; this page is the maintained model-and-firmware reference.

Explore the Bitaxe book
Read Bitaxe updates