DCENT_Toolbox FAQ

DCENT_Toolbox is a free, GPL-3.0, 0% dev-fee command-line toolbox — plus a keygen-style terminal UI — that scans, identifies, audits, recovers and re-flashes Bitcoin miners entirely from your own machine: no cloud, no licence server, no telemetry. It runs on Windows, macOS and Linux, but it launches from a Python 3.9+ source checkout: there is no PyPI package and no published binary or installer download. It drives four vendor backends, six firmware ecosystems and seven control-board families, and it reports only what it actually proved. The one command everyone starts with is dcent doctor <ip> — read-only, never destructive, and it tells you what to do next.

Getting started

What is DCENT_Toolbox?

It is an open-source command-line tool, plus a keygen-style terminal UI (TUI), for managing, recovering, auditing and re-flashing Bitcoin miners from your own computer. One tool scans your LAN, identifies each miner's vendor and firmware, reads its status, and — on hardware you own — can unlock locked units, audit firmware for hidden backdoors, build and write SD cards, install alternative firmware where a route exists, and prove a miner is actually hashing afterward. It is built by D-Central Technologies and released under the GPL-3.0.

How do I install DCENT_Toolbox?

Install from a full source checkout with Python 3.9 or newer. There is no PyPI package and no prebuilt installer to download yet, so installing it by package name will not work — clone the public GPL-3.0 repository and do an editable install:

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

paramiko ships as a core dependency, so SSH works out of the box on Windows with no extra setup, including miners that need legacy SSH crypto. Optional extras are additive on top of the same editable install; the keygen-style dashboard is the one most people want:

pip install -e ".[tui]"
dcent tui

Do I need Python to run it?

Yes. The current install path requires Python 3.9 or newer and a source checkout. No published binary: there is no download URL for a standalone dcent executable; a signed per-OS binary is a target, not a shipped artifact. Anyone telling you to download a dcent binary is describing something that has not shipped.

Is there a download link or a graphical app?

No published download URL, and no shipping GUI. The flagship interactive surface is the terminal UI — dcent tui — a keygen-style dashboard installed with the [tui] extra. A Tauri desktop app exists in the tree only as a scaffold that does not yet install, so the CLI and the TUI are the two real surfaces today.

Does it work on Windows, macOS and Linux?

Yes, all three, with the same CLI on every OS. DCENT_Toolbox is local-first and cross-platform. paramiko ships as a core dependency, so SSH works out of the box on Windows with no extra setup, including miners that need legacy SSH crypto. The only prerequisite that differs from a normal desktop app is the Python 3.9+ runtime and the source checkout.

What is the first command I should run?

Point it at any miner and run dcent doctor <ip>. It is the canonical first step for every user: read-only, never destructive, it reports firmware, board family and health, and tells you what to do next. To find the miners first, scan your subnet.

dcent scan --range 192.168.1.0/24   # discover miners on your LAN
dcent doctor 192.168.1.50           # read-only triage of one miner
dcent help getting-started          # browse the help topics
dcent tui                           # keygen-style dashboard

Cost, licensing and source

How much does DCENT_Toolbox cost, and is there a dev fee?

It is free and the dev fee is 0%. DCENT_Toolbox never inserts a developer fee, never adds a pool-fee skim, and never redirects any portion of your hashrate. One of its features actually detects and blocks a hidden dev-fee redirect found in certain closed-source third-party firmware images.

Does it phone home or need a cloud account?

No. There is no cloud tether, no remote account, no licence server and no telemetry. The tool runs 100% locally and talks only to the miners you point it at on your own network. The one optional outbound call is a public Bitcoin-network stats feed for the dashboard, which you can turn off.

Is it really open source, and where is the source?

Yes — GPL-3.0-only, with the full source public so owners and security researchers alike can audit exactly what the tool does. The repository is also the install source shown above, and it is the single source of truth for the current command surface and the per-board install reality.

# Public GPL-3.0 repository
https://github.com/DCentralTech/DCENT_Toolbox

What DCENT_Toolbox supports

Which miners and vendors does it support?

Four vendor ecosystems through four real backends: Bitmain/Antminer, MicroBT WhatsMiner, Canaan/Avalon, and BitAxe. Anything it does not recognise routes to a read-only generic cgminer backend — never a silent Bitmain write path — so an unknown miner is never accidentally treated as an Antminer.

Which firmwares and control boards can it detect and drive?

Six firmware ecosystems and seven control-board families, from one CLI. That is what lets the tool tell a Zynq-based S9 apart from an Amlogic-based S19j Pro or a Bitaxe Gamma and plan accordingly, instead of guessing from the model name on the sticker.

How big is DCENT_Toolbox?

Version 2.5.0 ships 491 Python modules and 87 CLI command modules, exposing roughly 75 user-facing top-level commands, backed by 4,500+ offline tests passing. Run dcent --help for the live command list — and treat that surface as inventory, not as permission to skip the route and proof checks below. A command existing is not the same as an operation validated on your miner.

Installing DCENT_OS

Can DCENT_Toolbox install DCENT_OS on my S19 right now?

No. 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. There is no one-click DCENT_OS install for a current-generation Antminer, and the toolbox shows those boundaries rather than pretending otherwise.

Why can't it just flash any Antminer?

Because the wall is hardware, not software. Stock Antminers ship with SSH disabled and, post-July-2019, RSA-signed firmware whose signing chain cannot be forged. Each board generation either has a software foothold that flips on Dropbear, or it does not — in which case a physical rail (SD card, USB-OTG, console) or an external eMMC reflash is the only way in. The table below is the honest per-board reality; only the S9 row is a public customer route, and every other row is a lab, manual or denied path.

Check your own unit rather than trusting a table: dcent support --flash-readiness and dcent install --list-routes report the routes actually available for that exact model, control board and incumbent firmware.

Which Bitaxe-class miners can install DCENT_OS for ESP?

Bitaxe-class ESP32-S3 miners do have real install routes today: Bitaxe Max, Ultra, Supra, Gamma, Hex Ultra and Hex Supra. A running AxeOS / DCENT_axe device updates over HTTP OTA; a first flash uses a USB serial factory package. Both routes require the companion signed manifest and its OTA public key — and upload acceptance is not boot, rollback, thermal or mining proof.

dcent install 192.168.1.42 -f <dcentaxe-update.bin> --dry-run
dcent flash --list-ports
dcent flash --serial COM3 -f <dcentaxe-factory.bin> --dry-run

Can it install alternative firmware at all, then?

Yes, but only through route-backed lanes, never as a blanket "any board". dcent install is dry-run/plan by default; the live write step executes only on an explicit operator confirmation (--yes). Where a board needs it first, 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. Every mutating operation resolves to an exact model, control board, incumbent firmware, evidence level and recovery route before it is offered — "package parsed" is never "safe to install".

Safety and trust

Is it safe — will it brick my miner?

It is built read-only first. dcent doctor and most recon commands are strictly read-only; every destructive action is dry-run by default and gated behind an explicit confirmation (a --yes flag or a typed confirmation in the UI); and the safety gates fail closed — if the tool cannot verify a unit is safe to write, it refuses instead of proceeding. Baked-in protections include a voltage clamp, a home-use fan cap, EEPROM write protection, atomic NAND environment writes instead of raw block writes, and a rule that cuts hash power rather than blasting fans on a fault. No tool can guarantee against a brick, but "detected" never means "safe to configure".

What do "operator-gated" and "proof-ladder" mean?

They are the two halves of the honesty model. Operator-gated means a feature is built and tested but the live write or execute step deliberately stops and waits for you to authorize it on your own hardware — the tool plans and constructs the exact commands but will not touch a live miner on its own. Proof-ladder means the tool reports exactly what it proved and no more: an upload is accepted, not "flashed"; a reachable device is online, not "mining"; a timeout is reported as unknown, never as success. dcent verify-mining classifies a post-install result as PROVEN, PARTIAL, FAILED or UNVERIFIABLE — a "hashing" verdict rests on a real accepted share, not mere reachability.

Routes carry one of five confidence labels: Production, Beta, Experimental, Recovery-only, and Detected-but-unsupported. Read them literally — "detected" is not "safe to configure", "a command exists" or "an adapter is present" is not "validated on your miner", and "package parsed" is not "safe to install".

Why does a command say it "can't" do something on my board?

Usually that is the tool being honest, not a bug. Some boards are hardware-fused with no software path, and some write paths are route-specific to an exact model, control board and incumbent firmware. Run dcent support --flash-readiness and dcent install --list-routes to see what is actually available for your unit, and never generalise one successful command on one miner to a whole platform family.

Can it find or remove hidden backdoors and dev-fee redirection?

Yes, on hardware you own. It can audit certain closed-source, third-party miner firmware images for hidden SSH backdoors, phone-home telemetry, remote-access vulnerabilities and silent dev-fee redirection. dcent audit reports what it finds against a catalog of known indicators, and dcent clean removes a known backdoor SSH key, kills the phone-home process, clears the device blacklist and blocks the embedded dev-fee redirect on affected images. These are defensive, owner-side capabilities: the tool describes what it detects and removes, and does not publish exploitation walk-throughs against any named vendor.

Is it legal to use?

DCENT_Toolbox is for authorized use only — hardware you own, or hardware you are explicitly authorized in writing to administer. Using its unlock, credential or flashing features against miners you do not control is illegal in most jurisdictions. The techniques it implements come from publicly documented research, published CVEs and independently reverse-engineered protocols; publishing them is what lets owners audit and repair their own equipment. Read SECURITY.md in the repository before you use the unlock or flash features.

Support

How do I share logs safely?

Redact them first. Raw mining logs contain your full Bitcoin payout address and pool credentials — treat those like a credit-card number:

dcent diag bundle --redact <ip>

The redacted bundle masks wallets, credentials, public IPs and MAC addresses automatically, so it is safe to attach to a bug report.

How do I report a result, a bug, or a security issue?

Route it by type. For usage questions, start with dcent help getting-started, the repository README and docs/GETTING_STARTED.md. For general bugs, feature requests and field results — including a route that worked or failed on your board — open an issue on the GitHub repository, and always include the exact context: toolbox version, vendor backend, exact command, miner model, control board, incumbent firmware and raw output. For a security vulnerability in the tool itself, do not open a public issue — email security@d-central.tech, where scope and safe-harbor terms are covered in SECURITY.md.

Who builds DCENT_Toolbox?

D-Central Technologies — a Bitcoin mining technology company operating in Québec since 2016. This is the bench toolbox we use ourselves, released under the GPL-3.0 so every operator can own, repair and understand their own hardware. If it saves you a board, you can fund the sovereign stack.

Where next

• DCENT_Toolbox: getting started — install and your first three commands
• Command reference — the ~75 top-level command surface
• Compatibility matrix — vendors, firmwares and the seven control-board families
• Discovery and scanning — finding miners on your LAN
• Installing DCENT_OS with the Toolbox — the honest per-board route reality
• DCENT_OS docs and the S9 SD trial — the companion open-source firmware
• Web flasher — browser-based flashing for supported ESP miners