Open firmware for the Hammer BC01. Measured on hardware: 1.6–1.7 TH/s at 750 MHz, 24 W, around 54 °C, no hardware errors.
Check your device before you flash
Retail BC01 units ship with Secure Boot enforced and both spare key slots revoked. On one of those this firmware will not boot and cannot be recovered — eFuses are permanent and USB access does not help. Ask the device first:
esptool.py --port COM3 get_security_info
If secure_boot_en is set, stop. The ESP32-S3 is a socketed
LilyGO T-Display-S3, so fitting a fresh module runs this firmware with no
exploit and leaves your original untouched — see
SECURE-BOOT.md and
HARDWARE-SWAP.md.
Open firmware for the Hammer BC04, four BM1370s in series. Measured on hardware: 6.1 TH/s at 750 MHz, 99 W, 65 °C, no hardware errors — or 5.1 TH/s at 72 W if you would rather have the efficiency.
Ethernet and WiFi both work
Ethernet on a BC04 is started after the hashboard is powered rather than before it. On the one BC04 whose Ethernet controller failed here, it was linked when the core rail stepped up, stopped answering about 70 ms later and never recovered. The firmware starts it at the safer point, and a BC04 hashing at 750 MHz serves its own interface over Ethernet with no errors.
That ordering is a precaution, not a known defect in your board. Measured on a healthy BC04 running the vendor’s own firmware on 2026-10-20: the controller linked 4.7 s into the boot and the core rail was not enabled until 22.8 s — linked and holding an address for eighteen seconds before the step — and it came through it and ran for the next hour without a dropped link. So the vendor’s ordering is not by itself fatal, and one failure should not be read as a property of the hardware. We start Ethernet later anyway, because it costs nothing and the one board that did fail was in exactly that state.
Confirmed both ways: with WiFi alongside, and with WiFi switched off entirely — which is what this image is until you set it up. On Ethernet alone it mined at 6.2 TH/s with no rejected shares and no hardware errors.
So plug in a cable and it works. If you would rather
set up over WiFi, the miner also raises an access point named
HAMMER_xxxx on first boot.
KNOWN-ISSUES.md has the measurements, including the four wrong theories that came first.
We have not measured a retail BC04's eFuses
The BC01 ships with Secure Boot enforced, and this firmware cannot boot on a locked module. Whether a retail BC04 is locked the same way is unknown to us — the BC04 tested here ran on a replacement LilyGO T-Display-S3, so its original module was never read. Do not assume it is open. Ask the device:
esptool.py --port COM3 get_security_info
If secure_boot_en is set, stop and read
SECURE-BOOT.md.
The module is socketed on this board too.
Not for BC02, BC06 or BC08
The board model is fixed when the firmware is compiled, and the boards do not share a pinout. The BC01 and BC04 have their ASIC UART lines swapped — TX 18/RX 17 against TX 17/RX 18 — so a BC01 image on a BC04 crosses transmit and receive. Pick the wrong one above and the miner boots, the web UI works, the chip is even detected, and it never returns a single share. The firmware catches that case now and says so on screen rather than looking like broken hardware, but the flash is still wasted.
The other models are supported in the source and can be built from it; only the BC01 and BC04 are published here, because only those two have been run on real hardware.
Flash the module before you fit it
On a BC04, or any Hammer powered through an XT-30, flash the controller module over USB with the module out of the miner, then fit it. Do not plug USB into a module already seated in a board running on main power.
The BC04 takes 12 V through the XT-30 and has no VBUS gate, so nothing on the board is documented to isolate USB 5 V from the rails that main power also drives. We have not measured what happens when both are connected, and we are not asking you to find out on your miner. Flashing the module on its own avoids the question completely: USB powers it perfectly well by itself, which is all the flasher needs.
A BC01 is different — it is USB-PD powered and has a VBUS gate, so flashing it in place is the normal way to do it.
Before you flash
This is unofficial firmware, written by an independent open-source miner. It is not affiliated with, endorsed by, or supported by Hammer, and flashing it may void your warranty with them.
It comes with no warranty of any kind — see sections 15 and 16 of the GPL-3.0 licence, served here alongside the firmware. You flash at your own risk. We are not responsible for damage caused by running a device beyond its limits, or by the flashing process leaving it unusable.
You are entitled to the source for the binaries on this page. SOURCE.txt names the exact commit they were built from and how to rebuild them — not “the latest main”, which stops being that commit as soon as anything else lands.
New install erases your configuration: WiFi credentials, pool settings and payout address all go. Note them down first. Update keeps them — but it asks about erasing the device on the way through, and ticking that box erases them after all.
Two protections in this firmware are known not to work, and both are documented rather than hidden: HARDWARE-SAFETY.md lists what stands between a fault and a damaged board, what has actually been tested, and what has not. Read it before you leave a miner unattended.
esptool instead.
Serial access needs a secure context — open this page over HTTPS.
Chrome or Edge on desktop. Connect the miner's ESP32-S3 by USB‑C first.
Nothing here mines to us
The image carries no credentials. Its settings partition is built from the public template, so a freshly flashed miner starts its own WiFi access point and waits for you to enter your network, your pool and your own payout address. Set an API password while you are there — leaving it blank disables authentication, which is how the vendor firmware shipped.
Or do it yourself
| Build from source | ESP-IDF 5.5.1. Full source, GPL-3.0. |
|---|---|
| Flash with esptool | esptool.py --chip esp32s3 write_flash 0x0 stay-open-bc01-full.bin |
| Update over the air | The miner's own Settings → Check for Updates does this
for you and picks the right files for your board. By hand, upload
-ota.bin (the firmware) and -www-ota.bin (the
web interface) on that same page — firmware first, interface
second, each one rebooting before the next. This keeps your settings and
never erases the flash, so it is the safer way to update. |
Every file, with digests, is on the releases page.