Mujina is a fast-moving open-source Bitcoin mining firmware project from the 256 Foundation, and as of today there is almost nothing written about it outside the project’s own pages. That’s a gap worth fixing, because Mujina is one of a small handful of serious attempts — alongside BraiinsOS+ and our own DCENT_OS — to put miners back in control of the machines they own. Here is what Mujina is, what it actually runs today, and where it fits.
What Mujina is
The project describes itself as “the Linux kernel of Bitcoin mining firmware: a single open source codebase that drives mining hardware from any vendor” (mujina.org). In practice, Mujina today is a mining daemon written in Rust — mujina-minerd — licensed GPL-3.0-or-later, published as a Cargo workspace at github.com/256foundation/mujina. The pitch is the same one every open-firmware project in this space shares: “Read every line, modify it without permission, control it through a documented API, and pay no dev fee. Own your firmware.”
The Linux-kernel analogy is deliberate architecture, not marketing. Core components — scheduler, pool protocols, API, monitoring — are written once; hardware vendors and community authors contribute drivers for their hashboards. The project openly says new hardware support “lives in forks” first, where rapid iteration happens before code stabilizes and merges into mainline (why-mujina). That honesty about fork-vs-mainline status is one of the most refreshing things about the project’s documentation.
Who builds it
Mujina is a 256 Foundation project, built in the open alongside two sister initiatives: the EmberOne/00 open hashboard (12×BM1362) and the Libreboard control board — hardware “designed from the start to run open firmware, with no reverse engineering required” (why-mujina). Community fork authors get named credit in the project’s own compatibility matrix: Schnitzel (Antminer S19j Pro / S19k Pro support) and johnny9 (Intel BZM2 driver work). The repository shows steady, active development as of August 2026.
Full credit where it is due: the 256 Foundation is doing this the right way — GPL license, documentation that distinguishes what works from what doesn’t, and a public forum. We build DCENT_OS in the same spirit, and the open-firmware movement is bigger than any one project. More auditable codebases driving more hardware is a win for every miner.
What Mujina runs today
The project’s hardware compatibility matrix (current as of July 2026) uses a status vocabulary we wish everyone used: Working means “runs in mainline Mujina today”; In progress means “code exists, but support is incomplete”; In a fork means “works, but in a fork that mainline may diverge from.”
| Hardware | Chips | Status (Mujina’s own labels) | Notes |
|---|---|---|---|
| Bitaxe Gamma | 1×BM1370 | Working (mainline) | ~1 TH/s at stock settings; mining, hardware monitoring and the REST API are functional |
| EmberOne/00 | 12×BM1362 | Working (mainline) | “Mainline support works today. The driver is being reworked and under active development” |
| CPU backend | — | Working (mainline) | A virtual board: software SHA-256 at a few MH/s per thread, for development and testing |
| Antminer S19j Pro, S19k Pro | BM1362-family | In a fork (prototype) | Lives in Schnitzel’s fork, powering RY3T Nova prototypes; “prototype software and an unsettled install path, not a replacement for stock firmware” |
| Intel BZM2 | Bonanza Mine 2 | In progress | Driver work in johnny9’s fork, bonanza branch; nothing merged into mainline |
One architectural detail matters more than anything else on this list, and nobody outside the project’s docs has spelled it out: on a Bitaxe, Mujina does not replace the firmware on the board. The Bitaxe runs bitaxe-raw — a pass-through firmware — and mujina-minerd runs on a Linux host, driving the ASIC over USB. Mujina is a host-side daemon today. The stated end goal is “Mujina OS: complete operating system images installed onto a miner’s control board” — but by the project’s own status page, “none exist yet.” For the S19 path, a separate repo (mujina-xilinx-platform) holds a working proof-of-concept: a Buildroot system with a ramdisk-replace boot bypass for stock S19 Xilinx Zynq control boards.
What works, and what doesn’t yet
Mujina’s status page is unusually candid. As of August 2026:
| Capability | Status |
|---|---|
| Stratum V1 (with version rolling) | Working |
| REST API — live state, pause/resume mining, Swagger UI | Working (v0, default bind 127.0.0.1:7785) |
| Temperature and hashrate monitoring | Working |
| Container image | Published |
| Autotuning / frequency / voltage / power controls | Not yet — “no frequency, voltage, or power controls, and no autotuning” |
| Stratum V2 | Not listed as working on the status page |
| Pool failover | Not yet — “connects to one pool at a time” |
| Published efficiency (J/TH) figures | None — no measured or published J/TH figures on any board |
| Prebuilt / installable OS images | None yet (roadmap: installable images for the Antminer S19 series) |
And the dev-fee question, since it’s the first thing everyone asks: Mujina charges no dev fee. Zero, by design, stated on the homepage and in the repo README.
Try it in ten minutes — no miner required
This is the part of Mujina’s documentation we admire most: the first-run tutorial requires no mining hardware at all. On any Linux machine with the Rust toolchain (via rustup) and the build dependencies (libudev-dev, libssl-dev on Debian/Ubuntu):
git clone https://github.com/256foundation/mujina.git
cd mujina
MUJINA_CPUMINER_THREADS=2 MUJINA_USB_DISABLE=1 cargo run --release --bin mujina-minerd
You get a complete miner stack hashing SHA-256 on your CPU and a REST API at http://127.0.0.1:7785/api/v0/. It won’t earn you anything — a few MH/s per thread is many orders of magnitude off the network — but you can read, run and instrument the entire pipeline before touching hardware. (DCENT_OS has the same zero-hardware on-ramp via its test suite and mock-telemetry dashboard preview — the 15-minute first run; we think this pattern should be table stakes for every firmware project.)
Mujina vs DCENT_OS vs BraiinsOS+ — verified facts only
These are three different answers to the same problem, at three different maturity points. Values below come from each project’s own published documentation and our firmware comparison matrix.
| Mujina | DCENT_OS | BraiinsOS+ | |
|---|---|---|---|
| Built by | 256 Foundation + community | D-Central Technologies | Braiins |
| Source model | GPL-3.0-or-later, full source | GPL-3.0 — daemon, dashboard and Buildroot | Closed binaries; BCB100 control-board hardware design is open |
| Mining engine | mujina-minerd (Rust) | dcentrald (Rust) | BOSminer (Rust) |
| Dev fee | 0% | 0% mandatory | 2–2.5% |
| Runs today on | Bitaxe Gamma + EmberOne/00 (mainline, host-driven over USB); CPU backend | Antminer S9 (Xilinx) + S19j Pro (Xilinx) — guarded beta artifacts with SHA256SUMS | Antminer S9, S17, S19, S21 — production |
| Antminer status | Prototype, in a fork (S19j/S19k Pro); “not a replacement for stock firmware” | Public beta — experimental, can brick, not for revenue-critical hardware | Production |
| Stratum | V1 (version rolling) | V1; V2 implemented in source, readiness-gated | V1 + native Stratum V2 in production |
| Autotuning | None yet | Implemented, build- and board-specific gating | Yes, production autotuning |
| Install format | Build from source or container; no prebuilt images | Downloadable signed images (guarded beta) | Installer/images per model |
| Honest one-line status | Experimental — the most exciting new codebase in the space | Public beta — real hardware images, guarded on purpose | The production benchmark for open-ecosystem Antminer firmware |
Who should try which today
- You run Antminers for income: BraiinsOS+ is the only one of the three you should put on production hardware today. It has autotuning, native Stratum V2 and years of field time. Neither Mujina nor DCENT_OS is production firmware, and both say so themselves.
- You have a spare S9 or S19j Pro and want open firmware on real industrial hardware: DCENT_OS is the shortest path — signed, checksummed beta images exist for those two boards, with a reversible SD-card trial path. Experimental; keep a recovery path; never on revenue-critical machines.
- You have a Bitaxe Gamma and a Linux box, and you want to hack on mining internals: Mujina is a genuinely great codebase to learn from — small, modern Rust, honest docs, and a no-hardware CPU mode to start with. (If you want firmware on the Bitaxe itself, that’s AxeOS or DCENT_axe — a different architecture than Mujina’s host-side model.)
- You want Mujina on an S19: wait for mainline, or follow Schnitzel’s fork only if “prototype software and an unsettled install path” sounds like a fun weekend rather than a warning.
Why we’re glad Mujina exists
Every closed firmware is a claim that you don’t really own your miner. Every serious GPL alternative — BraiinsOS+ pushing openness at industrial scale, Mujina building the shared-kernel model, AxeOS proving it on open silicon, DCENT_OS doing it our way — weakens that claim. We’re listed alongside Mujina in our own open-source mining registry not as competitors but as parallel bets on the same thesis: mining should be as open as the rest of Bitcoin. If Mujina’s S19 work mainlines, the whole ecosystem — including us — will learn from how they did it.
FAQ
Is Mujina production-ready?
No, and the project doesn’t claim to be. There are no prebuilt images, no autotuning, no pool failover, and Antminer support is prototype-in-a-fork. It is an experimental project under active development — see mujina.org/explanation/status.
Does Mujina charge a dev fee?
No. Zero dev fee, stated explicitly by the project. Like DCENT_OS, it treats your hashrate as yours.
Does Mujina run on an Antminer S19?
Only as prototype software in Schnitzel’s community fork (S19j Pro / S19k Pro), with what the project calls “an unsettled install path.” Mainlining S19-class support is a current focus, and a working proof-of-concept boot path for stock S19 Xilinx control boards exists at mujina-xilinx-platform.
Is Mujina the same kind of thing as AxeOS or DCENT_axe?
No. AxeOS and DCENT_axe run on the miner’s ESP32-S3. Mujina today runs on a Linux host and drives the Bitaxe over USB, with the board running the bitaxe-raw pass-through firmware. Different architecture, different trade-offs: host-side gets you a full Linux toolbox; on-device gets you a self-contained miner.
Does Mujina support Stratum V2?
Not per its status page today — it connects to Stratum V1 pools with version rolling. For the current SV2 landscape (BraiinsOS+ and AxeOS/ESP-Miner v2.14.0+ have native SV2), see our Stratum protocol matrix.
Where does Mujina fit in the open-firmware landscape?
See our open-source mining firmware options guide and the registry of open mining projects — Mujina is one of the open firmware projects tracked there.


