The Case for Open-Source Bitcoin Mining Firmware

Open-source Bitcoin mining firmware is the only kind you can verify, and verification is the whole point of Bitcoin. In September 2026 a community review of the newly published Bitfortun BS-1 source found a hard-coded +400 GH/s added to the hashrate shown on the device screen, a 7.8% inflation on a miner sold as 5.5 TH/s. That was catchable because the code was public. The Antbleed kill switch that shipped in Bitmain firmware sat unnoticed for years because it was not. This guide is for anyone who runs a miner, from a single Bitaxe on a desk to a container of S19s, and wants to know what firmware can do to them and how to check.

What is open-source Bitcoin mining firmware?

Open-source Bitcoin mining firmware is the software that runs a miner, published under a license that lets anyone read, build, modify, and redistribute it. Firmware controls everything the ASIC does that you can see: the pool it connects to, the shares it submits, the frequency and voltage it runs at, the fan curve, and the hashrate and efficiency numbers on the dashboard.

That last part matters more than people think. The ASIC chip does not report a hashrate. It reports solved nonces at a given difficulty, and the firmware turns those into the number you see. Every figure on a mining dashboard is a calculation someone wrote. If you can read the calculation, you can trust the figure. If you cannot, you are trusting the vendor. On a Bitaxe, that calculation is what turns accepted shares and difficulty into the dashboard figure, and it is also where the hashrate error percentage comes from.

“Open” has to mean the whole stack to mean anything. A vendor that publishes a web dashboard but keeps the hashing daemon as a binary blob has not opened the part that matters. The open-source standard in home mining, set by the Bitaxe lineup, is GPLv3 firmware plus CERN-OHL-S hardware files: schematics, PCB layout, and bill of materials.

Why did mining software start open, and how did cgminer start it all?

Bitcoin itself is open source, and for its first two years so was every miner that ran on it. The Bitcoin v0.1 client Satoshi released in January 2009 included its own CPU miner under the MIT license. Jeff Garzik’s standalone cpuminer followed in November 2010. In July 2011 Con Kolivas took over that codebase, rewrote it for GPU mining, and renamed it cgminer under the GPL. Luke Dashjr added FPGA support and later forked BFGMiner from it in 2012.

cgminer became the template for the ASIC era. When the first ASICs shipped in 2013, their manufacturers did not write miners from scratch; they wrote cgminer drivers. Bitmain’s own Antminer daemon, published as bitmaintech/cgminer and later bmminer, still carries the copyright lines “Copyright 2011-2014 Con Kolivas, 2011-2012 Luke Dashjr, 2010 Jeff Garzik” at the top of cgminer.c. The lineage from Satoshi’s CPU miner through cpuminer and cgminer to the machines securing the network today is unbroken. The hardware moved in lockstep, from CPUs to GPUs to FPGAs to ASICs, and the software followed each step.

What changed was not the code but who controlled the build. As mining professionalized, manufacturers kept the GPL heritage in their daemons but wrapped them in closed control-board images, added signature checks, disabled SSH, and stopped publishing the parts that touched revenue. The community had to reverse-engineer its way back in.

What can closed-source mining firmware do to you?

Closed firmware can do anything the hardware can do, and you have no way to know which of those things it is doing. Every item below has either happened or is explicitly sold as a feature somewhere in the industry today.

• Remote shutdown. A check-in to a vendor server that stops hashing on command, or on a spoofed reply. This is Antbleed (2017), covered below.
• Hidden fees. Redirecting a percentage of your shares to a developer wallet. Closed aftermarket firmware openly charges around 2–2.8% of hashrate; a hidden fee would look identical from the outside.
• Pool lock-in. Waiving the fee only if you point the machine at the vendor’s own pool, or silently changing which pool receives your work.
• Inflated numbers. Adding an offset to the displayed hashrate so the device appears to meet its spec. This is the Bitfortun BS-1 case, covered below.
• Telemetry. Reporting your MAC address, serial number, IP, and pool credentials to a server you did not choose. Antbleed did this on every check-in.
• Withheld efficiency. Implementing an optimization in silicon and enabling it only for the manufacturer’s own farms. This is covert ASICBoost.
• Silent updates. Changing any of the above after purchase, with signed-only images so you cannot roll back or replace it.
• Lock-out. Rejecting unsigned firmware, disabling SSH, and physically disabling the USB port so the owner cannot install anything else.

None of this requires malice to be dangerous. Antbleed’s server was unauthenticated, which meant a DNS hijack or a man-in-the-middle could have stopped most of the network without Bitmain lifting a finger. Closed code with a bug is as much of a risk as closed code with an agenda, and you cannot tell them apart.

What has Bitmain been caught doing?

Bitmain has been caught shipping a remote kill switch, implementing a covert efficiency exploit, and progressively locking owners out of their own machines. These are documented, not rumored, and Bitmain responded publicly to each.

Antbleed (2016–2017): a kill switch on roughly 70% of the network

Antminer stock firmware contained code that checked in with a Bitmain server at a random interval between 1 and 11 minutes, sending the machine’s MAC address, serial number, and IP. If the server replied with the string false, the miner stopped hashing. The behavior was first reported as an issue on Bitmain’s public bmminer repository in September 2016 and was publicly disclosed under the name Antbleed in April 2017, with the offending lines quoted in the trade press. Affected models included the S9, R4, T9, L3, and L3+, at a time when Bitmain hardware was estimated at around 70% of the network. Bitmain called it an unfinished anti-theft feature, said it had never been used without owner authorization, and released firmware that removed it.

The detail that matters for this article: the offending lines were in a piece of Bitmain’s stack that happened to be on GitHub. That is why they were found. The control-board image around it was not, and nobody knows what else was in there.

Covert ASICBoost (2017–2018): a 10–20% edge kept off the table

ASICBoost is a technique, patented by Timo Hanke and Sergio Lerner, that reduces the work needed per hash by roughly 10–20%. In April 2017 Bitcoin Core developer Gregory Maxwell disclosed that Bitmain’s chips had a covert form of it built in. Bitmain acknowledged the capability was in its silicon but said it had not used it on mainnet, citing patent uncertainty. In October 2018 it released firmware enabling the overt version for the S9 and other models. Customers who had bought those chips for years never had access to the boost until then. Whether the covert version was ever used in production is disputed to this day, and with closed firmware there is no way to settle it.

Signature locks (2019–2025): owners locked out of their own hardware

Starting with S9 firmware from mid-2019 and S17/T17 firmware from December 2019, Bitmain added signature checks so the web interface rejects any image it did not sign. S19 and S21 firmware from March 2024 does the same, as third-party firmware vendors document, and Amlogic-based control boards running stock firmware from September 2025 also disable the micro-USB port, closing the usual SD-card recovery route. Bitmain’s own security firmware Q&A confirms that SSH is disabled and that installing unauthorized third-party firmware voids the warranty. None of this improves hashrate. It removes the owner’s ability to choose. The moment third-party firmware is on the machine, things like running an Antminer on a standard 120 V outlet become possible, which is exactly what the locks prevent.

What did the Bitfortun BS-1 code audit find?

The BS-1 firmware adds a fixed 400 GH/s to the hashrate shown on the device’s screen, and the value it adds is not present in the upstream firmware it was forked from. The Bitfortun BS-1 is a single-chip BM1373 home miner launched in August 2026 and sold as 5.5 TH/s at about 95 W. On August 12, 2026 the manufacturer published its firmware source on GitHub under GPLv3, a fork of the NerdQAxe+ branch of ESP-Miner. Within four weeks, community reviewers were asking whether the 5.5 TH/s figure was real.

Here is what the published source does, as of commit bbd42bc on September 10, 2026:

• main/displays/displayDriver.cpp, lines 833–835. The function that updates the screen takes the 10-minute average hashrate from the system module and adds 400.0f (the firmware works in GH/s) before formatting it. It also uses that padded value to compute the efficiency figure shown next to it.
• main/history.cpp, line 102. The 1-minute hashrate returned by the web API adds 0.4 to the averaged value, with a comment about “uninitialized values.” At GH/s scale this is negligible, but the pattern is the same.
• The main hashRate field in the web API is not padded. The screen and the API disagree by 400 GH/s at all times.

The arithmetic is simple. If the screen shows 5.5 TH/s, the underlying 10-minute average is 5.1 TH/s, which is a 7.8% inflation. At the listed 95 W, the 17.3 J/TH displayed is really 18.6 J/TH. If the true rate is lower, the percentage is higher. The only number that cannot be padded is the one your pool computes from accepted shares, which is why we tell everyone to compare the dashboard against pool-side hashrate over 24 hours.

We cannot tell you why the line is there. It could be a leftover from a demo build, a misguided fudge to hit a marketing number, or something else. We have not bench-tested a BS-1 and do not stock it, so we cannot say what its true hashrate is. What we can say is that the offset exists, that it is not upstream, and that it took the community about four weeks from source publication to find it. That is the case for open-source firmware in one sentence.

Is open source a double-edged sword?

Yes. Freedom tech cuts both ways, and pretending otherwise is dishonest. The same license that let reviewers find the BS-1 offset let Bitfortun fork the NerdQAxe+ firmware in the first place. Open hardware files are why counterfeit Bitaxe boards exist, some with the wrong ESP32 module and no contribution back to the project. Anyone can take GPL code, add a line, and ship it.

But look at what the license also requires. GPLv3 obliges whoever ships the binary to publish the source. Bitfortun did, and that is precisely why the offset was found. A closed-source vendor adding the same line would never be caught, because there would be nothing to read. The double edge is real, and it still favors the reader: open source does not stop bad code from being written, it stops bad code from staying hidden.

Transparency is freedom in a practical sense. It is the freedom to check the number, to remove the line, to fork the project, to switch pools, and to keep using hardware after the vendor loses interest. Bitcoin only works because anyone can verify the chain instead of trusting a bank. Mining firmware should be held to the same standard.

How do Bitaxe and AxeOS put this into practice?

The Bitaxe is a fully open ASIC miner: hardware under CERN-OHL-S v2 and firmware, called AxeOS or ESP-Miner, under GPLv3. It was started in early 2023 by an electrical engineer known as Skot, and Open Source Miners United (OSMU), the Discord community founded in March 2023, became the home for it and for the NerdAxe, NerdQaxe, and NerdOctaxe projects that followed. OSMU projects publish schematics, PCB layouts, bills of materials, and firmware source.

What open firmware looks like day to day on a Bitaxe:

• You can read how the hashrate is computed. The figure on the AxeOS dashboard is derived from accepted shares and difficulty, and the function is in the repository for anyone to check.
• You can flash whatever you want. Flashing a Bitaxe takes any build, including your own. There is no signature check and no warranty clause against it.
• Safety features get added by the community, in public. AxeOS v2.13.0 started warning users about scam pools by checking the coinbase reward in the work the pool sends. That feature exists because someone in OSMU proposed it, someone wrote it, and everyone reviewed it.
• The hardware keeps improving on the same open terms. The Bitaxe Naja Duo, the first Bitaxe on the BM1373, ships with its design files public, like every model before it.

The trade-off is that OSMU devices use industrial silicon with no manufacturer documentation. The chips are the one closed component left in the home mining stack, which is why ASIC chip independence is the next problem to solve, and the 256 Foundation is working on it. The full source-code for the original Bitaxe esp-miner can be found at https://github.com/bitaxeorg/ESP-Miner. The full source-code for anything NerdAxe can be found at https://github.com/shufps/ESP-Miner-NerdQAxePlus.

What is Mujina, and what does it mean for industrial miners?

Mujina is a GPLv3 mining firmware written in Rust by the 256 Foundation, designed as a drop-in replacement for proprietary firmware on existing hardware and as the reference firmware for new open hardware. The 256 Foundation is a 501(c)(3) public charity that funds open-source mining work through four core grants: Mujina (firmware), Ember One (an open hashboard with twelve BM1362 chips), Libre Board (an open control board), and Hydra Pool (an open mining pool). The project calls itself “the Linux kernel of Bitcoin mining firmware”: a shared core with vendor and community drivers on top.

What Mujina runs today (August 2026)

According to the project’s own compatibility matrix, Mujina mainline runs the Bitaxe Gamma (one BM1370, about 1 TH/s at stock) and Ember One (twelve BM1362), plus a CPU backend for development with no hardware. Antminer S19j Pro and S19k Pro support exists in a community fork by Schnitzel, described by the project as prototype software with an unsettled install path. Intel BZM2 drivers are in progress in another fork. Stratum V1 with version rolling, a REST API, and temperature and hashrate monitoring work. Autotuning, frequency and voltage control, pool failover, and prebuilt installable images do not exist yet. Dev fee: zero, by design.

One architectural detail: on a Bitaxe, Mujina does not replace AxeOS on the board. The Bitaxe runs a pass-through firmware called bitaxe-raw, and the Mujina daemon runs on a Linux host driving the ASIC over USB. The stated end goal is complete OS images installed onto a miner’s control board, with the S19 series first, and a working proof-of-concept boot path for stock S19 Zynq control boards already exists in a separate repository.

Why this matters at industrial scale

For a farm running thousands of machines, firmware is a revenue and audit problem, not a hobby. Closed aftermarket firmware typically charges 2–2.8% of hashrate, often waived only if you mine on the vendor’s pool. On 100 PH/s that is 2–2.8 PH/s handed to a company that also runs a competing pool. Publicly traded miners have a second problem: they cannot demonstrate to an auditor that a closed binary is submitting every valid share, directing hashrate where the books say, or taking no hidden fee. Open, reproducible firmware is the only technical route to that assurance.

The strategic point is bigger than fees. If Mujina mainlines S19-class support and Ember One hashboards ship in volume, an operator could run a rack where the pool, the firmware, the control board, and the hashboard are all open, and only the ASIC die itself is closed. That is the same shape as the home stack today, scaled up, and it would end the manufacturer’s ability to reach into a deployed fleet with a signed update. Tether’s open-source MiningOS, announced earlier this year, is a sign that large operators see the same risk.

The honest caveat: Mujina is experimental, has published no efficiency figures, and nobody should run it on revenue-critical hardware today. The project says so itself, which is another thing open projects can do that closed ones rarely will.

Closed vs open firmware compared

This table compares the three kinds of firmware a Bitcoin miner can run today, using each category’s own published terms and the incidents documented above.

Sources: Bitmain support pages and the Antbleed disclosure (2017); the 256 Foundation’s published dev-fee figures for closed aftermarket firmware; the Bitfortun BS-1 repository at commit bbd42bc; the Bitaxe and Mujina repositories. Compiled September 10, 2026.

What we found in the code

We did not take the BS-1 claim on faith. On September 10, 2026 we cloned the published repository, read the hashrate paths, and checked the upstream firmware’s entire history for the same lines. Here is the method and what came out of it.

Method. Cloned liaojinguu/bitfortun-BS-1 at commit bbd42bc (project initialized August 12, 2026, eight commits total, GPLv3 license file present). Cloned shufps/ESP-Miner-NerdQAxePlus, the codebase the README says it is derived from, with full history. Traced every call that feeds a hashrate value to the display or the HTTP API, then ran git log -S on upstream for each offending string.

Findings.

• • In the BS-1 code, DisplayDriver::updateHashrate() reads SYSTEM_MODULE.getCurrentHashrate() + 400.0f twice: once to compute the displayed efficiency and once to format the displayed hashrate. In upstream the same two lines read SYSTEM_MODULE.getCurrentHashrate() with no offset, and the string +400.0f has never appeared in upstream’s commit history.
  • On the BS-1 board (bitfortunqaxeplus2.cpp, which sets m_hasHashCounter = true), getCurrentHashrate() returns the BM1373’s smoothed hardware hashrate counter in GH/s. The 400 is added on top of whatever the chip reports, so the offset is exactly 400 GH/s, or 0.4 TH/s, at all times.
  • In history.cpp, getCurrentHashrate1m() returns the 1-minute average plus 0.4, and the same file offsets a freshly allocated history buffer by 400 elements, with a comment about uninitialized samples. Whether that is intentional or a copy-paste error, neither line has ever existed upstream.
  • The primary hashRate field in the fork’s /api/system/info response is not padded, so a user comparing the screen to the API, or to their pool, will see the gap.

What we did not find. We searched the whole firmware for hard-coded pool hosts, Bitcoin addresses, and fee logic. The only URLs in the code are public block-explorer lookups for price, block height, and fees, plus an NTP server; there are no address literals and no fee code. On that basis we found no pool redirection, hidden wallet, or share withholding. The offset is limited to what is displayed. We also cannot verify that the binary shipped on the device matches this repository; only a reproducible build would settle that, and that is the next standard open projects should adopt.

How to check what your own miner is reporting: step by step

1. Note the dashboard hashrate. On a Bitaxe, open AxeOS and record the hashrate after at least 10 minutes of uptime so the average has settled.
2. Read the API. Open http://[miner-ip]/api/system/info in a browser and compare hashRate to what the screen and dashboard show. On open firmware they should match within rounding. A fixed gap is a red flag.
3. Compare against the pool. After 24 hours, check the pool’s reported hashrate for your worker. Pool-side hashrate is computed from accepted shares and cannot be padded by the device. Expect 5–10% variance from luck; expect it to average out.
4. Check the error rate. A high error percentage on the dashboard means the chip is producing bad nonces, which a dishonest firmware could hide by counting them anyway.
5. Read the source, or find someone who has. If the vendor publishes firmware, search the repository for the function that formats hashrate. If the vendor does not publish it, you have your answer about what you can verify.
6. Prefer hardware whose firmware you can replace. Every AxeOS-based Bitaxe can be reflashed with the Bitaxe webflasher or ESP Tool for custom firmware.

Bottom line

If you run a home miner, buy open hardware with open firmware and check its numbers against your pool once. A Bitaxe-class device costs less than a signature-locked control board, and you will never wonder what the screen is hiding. If you run an industrial fleet, watch Mujina and the 256 Foundation closely, contribute hardware or engineering time if you can, and start asking your firmware vendor for reproducible builds, because Antbleed-style risk is sitting on your balance sheet whether or not it ever fires.

Open source does not make software honest. It makes dishonesty visible, and in a system built on “don’t trust, verify,” visible is the whole game. The 400 GH/s in the BS-1 source was found in weeks. The Antbleed check-in ran for years. That gap is the case for open-source mining firmware, and the whole community, from OSMU to the 256 Foundation, is working to make it the default at every scale.

Related reading

• What is Bitaxe? The open-source Bitcoin miner explained
• AxeOS explained: the Bitaxe firmware dashboard
• Scam pool detection in AxeOS
• The open-source Bitcoin mining revolution
• DATUM and Stratum V2: miners building their own blocks
• Bitcoin mining decentralization: challenges and innovations