Supported Miners, Firmwares & Control Boards

DCENT_Toolbox 2.5.0 is one open-source, fee-free command-line tool that detects the vendor, identifies the firmware and fingerprints the control board of a Bitcoin miner, then offers only the actions that are safe for that exact combination. It drives 4 real vendor backends (Bitmain, MicroBT WhatsMiner, Canaan/Avalon, BitAxe), detects and manages 6 firmware ecosystems, and understands 7 control-board families spanning the Antminer S9 through the S21. Anything it cannot positively identify routes to a read-only generic cgminer backend — never a silent Bitmain mis-route. Support here is stated per route, not per model, so “the adapter exists” is never mistaken for “this operation is validated on your miner.” 0% dev fee, no cloud, no license server, GPL-3.0.

What does “supported” actually mean here?

DCENT_Toolbox reports exactly what it proved, never more. “Detected” is not “safe to configure.” “Adapter present” is not “operation validated.” “Package parsed” is not “safe to install.” Every mutating operation must resolve to an exact model, control board, incumbent firmware, evidence level and recovery route before it will run — dcent install is dry-run/plan by default, and the live write step executes only on an explicit operator confirmation (--yes) and the proof-ladder.

Because of that, this page uses five plain confidence levels. Read them before you trust any row below.

Confidence levels used on this page

Read this before you read the tables

A marketing name is not a control board. The same “S19j Pro” ships on am2-XIL (Xilinx Zynq), am3-BB (TI AM335x BeagleBone), am3-AML (Amlogic A113D) and cv1835 (Cvitek) — four different silicon realities with four different answers to “can I flash this.”

So the toolbox refuses to guess. A model name alone never silently selects a control board when more than one family fits; a generic soc=zynq observation stays {am1, am2} rather than resolving to am2. An ambiguous identity stays ambiguous until an independently observed --board-family or an SSH/HTTP SoC signal disambiguates it. That is by design, not a gap.

Which vendor backends does DCENT_Toolbox drive?

Four real backends plus a read-only fallback. The write column is what the backend is capable of driving — not a promise that a given write is validated on your unit.

An optional Rust device-abstraction extra, asic-rs (dcent scan --use-asic-rs), can widen the read-only device matrix beyond the four native backends, and degrades cleanly when it is not installed. That is a read matrix, not a write matrix.

Why the fallback matters

The single most expensive failure mode in a mixed shop is a tool that assumes Bitmain because the miner answered on port 4028. Multi-vendor detection sets make=BITMAIN only on a positive Bitmain signal. Everything else lands in the generic cgminer read path.

Which firmwares can it detect and manage?

Six firmware ecosystems are detected and driven from one CLI — for inspection, recovery planning and route-specific install support.

Revert footnote: “Remove accepted” is not “stock observed.” DCENT_OS and LuxOS uninstall.sh are the proven revert lanes; BraiinsOS+ and VNish remove paths are code-complete and operator-gated, with live proof still pending.

The firmware audit is an owner-side defensive capability: some closed-source third-party miner firmware ships hidden SSH backdoors, phone-home telemetry, a device blacklist, or silent dev-fee redirection. dcent audit detects these and dcent clean removes them from hardware you own. The firmware names in the table above are simply the firmwares the toolbox can detect and manage — the list is a capability statement, not an accusation about any of them.

Which control boards map to which Antminer generations?

Seven families: six Antminer control boards plus the ESP32-S3 Bitaxe class. What is possible per family depends on the hardware, not on software effort — the firmware-signing chain on newer Antminer boards is a real wall.

The generation walk, in one line

S9 (am1-XIL) → S17/T17 (am2-XIL) → S19/T19 (am2-XIL, am3-BB) → S19 XP / S19k (am2-XIL, am3-AML, cv1835) → T21/S21 (am2-XIL, am3-AML, cv1835). The board families overlap the marketing generations; they do not map one-to-one, which is exactly why identity has to be resolved per unit and never per model name.

Can it install DCENT_OS on any Antminer? The honest per-board reality

No — not on every board, and not yet for most of them. “Install custom firmware on any Antminer, software-only” is not true. Stock units ship with SSH disabled and, post-July-2019, RSA-signed firmware; getting a root foothold hits a generational hardware wall. DCENT_Toolbox is explicit about exactly where each rung holds, and keeps unlock, route, artifact and proof state separate.

Identity granularity matters inside a single row: an S19k Pro on cv1835 is detected but unsupported as a customer install, and it is never merged with the Amlogic S19k row.

Bottom line: only the Antminer S9 (am1-XIL) has a public network-write / SD-trial route today. Every current-generation Antminer (S17 / S19 / S19j Pro / S19k Pro / S21) stock first-install is lab-gated, evidence-gap, or no-customer-write. BitAxe / ESP devices have real OTA/USB routes. It is not one-click and it is not available to end users yet on Antminer stock. Those rows describe route-backed readiness, not a blanket write promise: the live write step sits behind explicit operator confirmation and the proof-ladder, and unlock and flash features are for hardware you own or are explicitly authorised to administer.

Can it install DCENT_OS for ESP on Bitaxe-class miners?

Yes — the ESP tier is the one place a customer has genuine rails. Running AxeOS / DCENT_axe devices update over HTTP OTA; a first flash uses USB serial. Model-pinned routes require the companion DCENT_axe manifest, and the toolbox validates boardTarget, deviceModel, payload SHA-256, the factory flash map and ota.updateFitsSlot before any upload or image write.

Upload and image-write acceptance is not boot, rollback, thermal, or mining proof. LoRa mesh remains planned and default-OFF in the firmware binary.

Which platforms are proven mining on DCENT_OS?

The companion firmware, DCENT_OS, has been proven mining on five distinct platforms, and dcent verify-mining encodes a cold-boot proof ladder for each:

• am1 — Antminer S9 (BM1387)
• am2 (Zynq) — Antminer S19 Pro (BM1398) and S19j Pro (BM1362)
• am3 (BeagleBone) — Antminer S19j Pro (BM1362)
• am3 (Amlogic) — Antminer S21 (BM1368)

Mining proof is a firmware achievement, not a first-install permission. Mining-proof admission cannot certify an ambiguous identity or a stock first-install evidence gap.

How do I check my own miner?

Start read-only. dcent doctor is the canonical first step for every persona: it triages vendor, firmware, board and next steps, never writes and never destroys anything. Feed a fingerprint into the control-board router to see the exact route kind, commands and proof ceiling before you go anywhere near a write path.

dcent doctor 192.168.1.50                        # read-only triage: vendor, firmware, board, next steps
dcent fingerprint 192.168.1.50 --json > fingerprint.json
dcent controlboard-route --fingerprint-json fingerprint.json --json
dcent controlboard-route --list-targets --json   # route kind, commands, and proof ceiling
dcent install --list-routes                      # the install routes the toolbox knows

List the routes and run a --dry-run before assuming a write path is proven for your unit. If the router leaves you ambiguous, that is the correct answer, not a failure.

How do I install DCENT_Toolbox?

DCENT_Toolbox runs locally on Windows, macOS and Linux, but launch requires Python 3.9+ and a source checkout. There is no PyPI package and no published binary installer — install from the public GPL-3.0 repository:

git clone https://github.com/DCentralTech/DCENT_Toolbox.git
cd DCENT_Toolbox
python -m pip install -e .

The keygen-style TUI (dcent tui, via the [tui] extra) is the flagship interactive surface. The Tauri desktop GUI in the tree is a scaffold that does not yet install, and there is no published Windows/macOS/Linux download URL — one trustworthy signed binary per OS is a target, not a shipped artifact. Drive the toolbox from the CLI or the TUI.

Where the toolbox is weakest

Publishing the limits is the point of a support matrix. As of 2.5.0:

• Vendor first-install is not one-click. The S9 is the only public-beta network write path; the rest is evidence-gap or lab-gated.
• Prepare/unlock is plan-only. The rail is ranked and the recommended archive is built in-process with a reported SHA-256, but nothing is uploaded and dcent unlock is not executed against a miner. Ambiguous boards never get a generic unlock.
• Discovery is neighbour-first. Fresh ARP/UDP first, then a cheap presence probe, then identify only the responders. MAC and model hints are never identity. Mature single-vendor fleet tools still beat us on raw LAN presence speed and one-pass fleet rows — that is an honest gap we are closing, not a claim about anyone else’s product.
• Launch requires Python and a source checkout. No installer, no PyPI package, no binary download.

How is this different from the rest of the category?

Positioning by honest capability, not by attacking anyone. DCENT_Toolbox is:

• 0% dev fee, 0% pool-fee adder, 0% license-server gating. There is no fee lever to pull, because there is no fee mechanism in the code.
• 100% local. No cloud tether, no remote account, no license activation, no telemetry. It runs entirely from your laptop or lab bench and never phones home.
• Multi-vendor by construction. Four vendor backends and six firmwares behind one CLI and one TUI, with a read-only fallback for gear it does not recognise — instead of one vendor’s firmware installing itself.
• GPL-3.0-only, source published. Every claim on this page is checkable against the repository, including the ones that say “no.”

DCENT_Toolbox is built by the Mining Hackers at D-Central Technologies in Québec — a Bitcoin mining technology company operating since 2016. We open-source the tools we use on our own bench because operators should be able to own, inspect and repair their own hardware.

Scale, for context: version 2.5.0 ships roughly 75 user-facing top-level commands with 4,500+ offline tests passing, across 491 Python modules and 87 CLI command modules.

Credits

This work stands on published open-source research. The hashboard EEPROM decryption algorithm and key tables are derived from — and kept byte-identical to — skot/amlogic-cb-tools (GPL-3.0). The ASIC drivers, APIs and protocols were informed by ESP-Miner (GPL-3.0), pyasic (Apache-2.0) and asic-rs (Apache-2.0).

Where next

• DCENT_Toolbox — the toolbox overview and docs index
• Getting started — install from a source checkout and run your first read-only triage
• Commands reference — the ~75-command surface, grouped by what it touches
• Discovery — how neighbour-first scanning finds miners without a CIDR sweep
• Installing DCENT_OS with the Toolbox — the route ladder and its gates
• Toolbox FAQ
• DCENT_OS — the companion GPL-3.0 mining firmware · First run · S9 SD trial · Uninstall · DCENT_OS FAQ
• Web flasher — browser-based flashing for Bitaxe-class ESP devices
• Fund the Sovereign Stack — keep the fee-free tools fee-free