WhatsMiner Firmware Guide: M30S to M60S — Update, Recovery & Custom Firmware

WhatsMiner Model Families: M30S Through M60S

Understanding which hardware generation you own determines which firmware paths are available to you. MicroBT follows a clear naming convention: the letter S after the model number indicates a higher-efficiency bin, and additional + or ++ suffixes represent top-tier efficiency variants from the same silicon run.

Sources: Specifications from MicroBT product documentation and D-Central internal hardware research (2026). The M70/M70S series (2025, 14.5–13.5 J/TH) follows the same architecture on the H616/CB6 platform.

Stock WhatsMiner Firmware Architecture

MicroBT ships every WhatsMiner model with a custom Linux distribution running btminer — a proprietary mining daemon developed in-house. This is not a CGMiner fork. btminer was written from the ground up to communicate with MicroBT’s hash boards directly over the SoC GPIO/SPI/UART buses, without the FPGA midstate engine that Bitmain’s architecture relies on.

What the Stock Firmware Includes

• btminer daemon — handles pool connections, work distribution, nonce submission, and board management
• Web UI on port 80 — dashboard for pool configuration, status monitoring, and firmware updates
• btminerAPI on port 4028 — a custom JSON-RPC protocol (not CGMiner-compatible despite the same port)
• WPA2 networking — Ethernet only on standard models; Wi-Fi not standard
• OTA update channel — firmware can be delivered via the API or tool-assisted network push

What Stock Firmware Does Not Include

• Per-chip auto-tuning (performance is managed at the board level with uniform frequency targets)
• Stratum V2 support (Stratum V1 only — see our Stratum V1 vs Stratum V2 guide)
• Granular power targeting (no watt-level control out of the box)
• Curtailment / demand-response API

The btminerAPI Protocol

The WhatsMiner API uses the same TCP port (4028) as CGMiner, but the protocol is MicroBT’s own design — the btminerAPI V2.0.5 (documented August 2024). A critical operational detail: the API has two tiers.

Write commands use a token-based encryption scheme: the client requests a get_token response containing a time, salt, and newsalt; derives an encryption key from the admin password and salt; encrypts the command payload; and sends the encrypted payload with the token. This is not a limitation to work around — it is the intended API security model.

How to Update WhatsMiner Firmware

MicroBT provides three official update paths. The right method depends on whether your miner is reachable over the network and whether you are doing a routine upgrade or recovering from a failed flash.

Method 1: WhatsMinerTool (Standard Updates)

WhatsMinerTool is MicroBT’s Windows utility for batch management. It handles firmware uploads, API write-enable toggling, password changes, and network scanning. Download it from the official MicroBT support page before beginning.

1. Download the target .bin firmware file from MicroBT’s official support page for your specific model. Verify the SHA-256 checksum.
2. Install and launch WhatsMinerTool on a Windows machine on the same network segment as your miners.
3. Use the IP scan function to discover your miner(s). Confirm the model matches the firmware file you downloaded — flashing the wrong model image will brick the machine.
4. Select the firmware file, select the target miner(s), and initiate the update. The tool uploads and verifies the signed image before flashing begins.
5. Wait for the miner to reboot. The process typically takes 3–5 minutes. Do not cut power during this window.
6. Confirm the new firmware version via the web UI or {"cmd":"get_version"} API query.

Method 2: SD Card Recovery

When network-based updates fail — failed flash, corrupted bootloader, or device not reachable — SD card recovery is the path back. MicroBT uses the PhoenixCard utility to write bootable recovery images.

1. Download the SD card recovery image (.img) for your exact model from MicroBT’s support tools page.
2. Write the image to a microSD card (8 GB minimum, Class 10) using PhoenixCard on Windows. Do not use Balena Etcher or Win32DiskImager for this — PhoenixCard writes a specific Allwinner boot format.
3. Power off the miner completely. Insert the SD card into the control board’s microSD slot with contacts facing up.
4. Power on the miner. The red LED on the control board will blink rapidly, indicating the SD card flash process is running. Do not power off.
5. Wait until the LED pattern changes (typically solid or slow blink) indicating flash completion — usually 3–8 minutes depending on the image size.
6. Power off, remove the SD card, then power on normally. The miner will boot to factory firmware.

Method 3: API OTA (Newer Models)

The update_firmware write command enables programmatic OTA updates on supported models. This requires write API to be enabled and authenticated. Consult MicroBT’s btminerAPI V2.0.5 documentation for the payload format. This method is primarily used by fleet management tools and is not recommended for single-miner manual updates.

Signed Firmware: MicroBT’s Deliberate Design Philosophy

WhatsMiner firmware images are cryptographically signed by MicroBT. The device verifies the signature before flashing any image. Unsigned binaries are rejected. This is a security architecture decision, not a technical limitation or anti-competitive maneuver — and understanding it neutrally is important for operators making long-term hardware decisions.

What Signing Achieves

• Supply chain integrity: Miners that travel through multiple reseller hands arrive with verifiable, unmodified firmware. An operator in a large hashcenter can confirm no firmware tampering occurred in transit.
• Reduced attack surface: A signed-firmware device cannot be reflashed with arbitrary code via the update mechanism, even if an attacker gains API access or physical network access.
• Warranty and support clarity: MicroBT can confirm whether a machine is running official firmware when handling RMA claims — a meaningful operational benefit for fleets under service contracts.

The Trade-Off

The same signing requirement that improves security also constrains modification. Operators who want per-chip autotuning, power targeting, or features absent from stock firmware must work through paths that bypass or replace the signing chain. Those paths exist — but they are more involved than the simpler SD-card flash approaches used for some other ASIC architectures. This trade-off is a legitimate design choice that different operators will weigh differently based on their fleet profile, risk tolerance, and operational goals.

For a cross-vendor comparison of how different manufacturers approach firmware openness and control, see our firmware comparison hub.

The Third-Party Firmware Landscape for WhatsMiner

The WhatsMiner custom firmware ecosystem is smaller than the Antminer ecosystem but active. Three distinct approaches exist, each with different trade-offs.

Performance-Optimized Third-Party Firmware

Several third-party firmware projects have developed support for WhatsMiner models, particularly the M3x (M30S series) and M5x generation. These projects ship per-chip autotuning algorithms that identify each chip’s stable frequency ceiling — a capability absent from stock firmware — which typically yields measurable efficiency and hashrate improvements. The approach differs meaningfully across projects in how they derive chip targets, their curtailment implementation, and how they handle the signed-firmware constraint at flash time.

We maintain a detailed feature-by-feature breakdown across firmware platforms in the D-Central firmware feature matrix. The Antminer-focused breakdown at custom Bitmain firmware explained provides useful architectural context, though the WhatsMiner and Antminer execution paths differ at the control board level.

ePIC UMC: Hardware-Level Solution for M3x and M5x

The ePIC UMC (Universal Mining Controller) takes a different approach than firmware patching: it physically replaces the WhatsMiner control board. Because the signing check runs on the control board hardware, replacing that board with ePIC’s V5 board running their PowerPlay firmware bypasses the signature requirement entirely. The hash boards remain unchanged; only the controller is swapped.

Key characteristics:

• Compatible with M3x (M30S, M31S, M32) and M5x (M50, M50S) series
• No dev fee (PowerPlay firmware charges no hashrate fee)
• Enables overclocking and undervolting profiles not available via software alone
• Requires physical access to each miner — not suitable for remote-only fleet management
• The original control board is preserved and can be reinstalled

D-Central carries the ePIC Blockchain UMC Universal Mining Control Board. Contact us for fleet pricing and compatibility confirmation for your specific board revision.

BraiinsOS: Not Compatible With WhatsMiner

BraiinsOS and BraiinsOS+ support Antminer S9, S17, S19, and S21 series exclusively. Braiins’ tooling can discover and monitor WhatsMiner units via the btminerAPI for unified fleet visibility, but flashing BraiinsOS to a WhatsMiner is not technically possible — the architectures (Allwinner ARM vs. Xilinx Zynq/Amlogic) are incompatible and Braiins has not announced WhatsMiner support.

Fleet Management and Monitoring Tools

Even without third-party firmware, WhatsMiner fleets can be managed efficiently at scale through the btminerAPI and compatible open-source tooling.

pyasic: Open-Source Multi-Vendor Management

The pyasic library (Apache-2.0) provides a standardized async Python interface for WhatsMiner models including the full M2X, M3X, M5X, and M6X generations. It abstracts the btminerAPI token encryption for write operations, handles model auto-detection, and returns normalized MinerData objects regardless of vendor.

Supported operations via pyasic on WhatsMiner: hashrate/power/fan data, pool configuration read/write, reboot, stop/resume mining, fault light control, and power limit setting.

Monitoring Best Practices

• Enable write API before deployment: WhatsMinerTool must be used once per machine to enable write API and set a non-default admin password. Units with write API disabled can only be read-monitored remotely.
• Single-threaded API constraint: The btminerAPI is single-threaded — only one connection at a time. Fleet polling tools must queue requests sequentially per miner, not fan out concurrent connections to the same unit.
• Network isolation: WhatsMiner units on the same VLAN should not have their management port exposed to the internet. The token scheme provides write protection, but read commands expose pool credentials.

For pool selection and optimization guidance that pairs with your firmware choice, see our mining pool comparison and the ASIC profitability leaderboard to benchmark your current efficiency against current network conditions.

Troubleshooting Common WhatsMiner Firmware Issues

For physical board-level diagnostics beyond firmware issues — connector damage, capacitor failure, or chip-level faults — see the ASIC repair guide and repair cost estimator. Our field manual covers maintenance procedures for WhatsMiner and Antminer in fleet contexts.

DCENT_OS and WhatsMiner

DCENT_OS is D-Central’s GPL-3.0 mining firmware project, currently in closed beta with public beta targeted for summer 2026. The initial focus is Antminer S19/S21 generation hardware, where the existing open-source tooling (ESP-Miner ASIC drivers, BCB100 control board hardware, Mujina Rust drivers) provides the most complete foundation.

WhatsMiner support is a longer-term consideration. The Allwinner H-series SoC architecture differs meaningfully from the Zynq/Amlogic targets — no FPGA midstate engine means the ASIC communication layer must be implemented differently. The btminer binary is not open-source and cannot be reused. The ePIC UMC hardware-replacement path demonstrates that custom control board development for WhatsMiner is feasible; it represents a significant engineering investment to do well.

DCENT_OS documentation is at dcent-os/docs. Questions about WhatsMiner compatibility roadmap can be directed through the contact form.

Frequently asked questions

Related Resources

• Firmware comparison hub — cross-platform feature matrix (stock, BraiinsOS+, third-party options, open-source)
• Custom Bitmain firmware explained — how the Antminer ecosystem differs architecturally
• Firmware feature matrix dataset — structured data, CC BY 4.0, API-accessible
• Stratum V1 vs. Stratum V2 — protocol comparison and mining pool implications
• Mining pool comparison — FPPS vs. PPLNS, fee structures, MEV policy
• ASIC repair guide — hardware diagnostics for WhatsMiner and Antminer
• PSU repair guide — power supply diagnostics and compatibility
• Repair cost estimator — benchmark repair economics vs. replacement
• ASIC profitability leaderboard — live efficiency rankings including WhatsMiner models
• Field manual — fleet maintenance procedures and operational guides
• ePIC UMC control board — hardware replacement for M3x/M5x series
• Open-source miners — Bitaxe and open-source mining hardware
• Mining academy — foundational guides for all levels
• DCENT_OS documentation — D-Central’s GPL-3.0 firmware project (closed beta)