Skip to content
Small team, full backlog, zero orders dropped. Support replies are slower than we’d like. Read our status update → Zero orders dropped. Status → 📬 Check your spam folder — most of our replies land there. We do answer. Status update → 📬 Check your spam folder. Status →

Read-only identity check

Identify Your WhatsMiner Platform Before Firmware or Recovery

A chassis model is not a recovery identity. Record the platform reported by the miner, then check the exact model class and any visible board marking. If those records disagree, do not flash.

Collect identity without changing the miner

Current API v3

The manufacturer’s read-only get.device.info response includes system.platform, system.control-board-version and system.fwversion. Copy only those identity values.

Legacy API v2

The read-only get_version response includes platform, miner_type and fw_ver. Preserve the returned spelling, including H6OS.

Physical record

If a board marking is already safely visible while the unit is powered off, photograph and record the full code. A board code by itself does not prove the API platform.

Manufacturer references: WhatsMiner API documentation, firmware and recovery catalog, and control-board Q&A. Reviewed August 27, 2026.

Platform identity check

Use the platform value returned by the miner. If you do not have it, the result must remain unresolved.

Use the API or normal interface value—not a guess based on the model.
Enter only the board code, not a serial number.

Waiting for an identity record

No data leaves this page.

What the current recovery catalog actually establishes

H3

Generic recovery scope: M2x and M3x. Separate entries exist for M3 and for M10/D1.

H6

Generic recovery scope: M2x and M3x. A separate entry exists for M10/D1.

H6os

Generic recovery scope: M2x, M3x and M5x. A separate entry exists for M10/D1.

H616

Generic recovery scope: regular M3x, M5x and M6x. M54/M64 has a separate entry. Public M7x recovery scope is not established.

Recovery scope is not updater scope. A current unified updater can cover models that the public recovery entry does not name. Never infer recovery media from an updater’s model list.

Board code, platform and compatibility are different facts

The manufacturer currently associates CB6_V10 with air cooling, CB6_V5 with hydro and CB6_V7 with immersion. It also documents a CB4-to-CB6 replacement case. That means a compatibility statement does not prove that two boards share a platform, processor, recovery image or firmware package.

  • Preserve the raw API platform value and full board marking.
  • Do not convert CB4, CB5 or CB6 into H6, H6os or H616 by assumption.
  • When label, API and board evidence conflict, stop and request identification help.

Choose the next safe route

WhatsMiner platform identification questions

Why is the chassis model not enough to choose firmware?

Manufacturer recovery scopes overlap across model families and are separated by reported platform. The exact model remains important, but it cannot safely substitute for H3, H6, H6os or H616 identity.

What information can I safely collect without opening the miner?

Record the exact model label and the read-only platform, control-board-version and firmware-version fields shown by the normal interface or manufacturer API. Do not share credentials, serial numbers, MAC addresses or private network details.

What if the dashboard model and chassis label disagree?

Treat the identity as unresolved. Preserve both values, do not flash or order a board, and request diagnosis.

Can DCENT_Toolbox verify a reachable miner?

DCENT_Toolbox can help collect read-only live identity from supported reachable miners. This page does not connect to a device and evaluates only the values entered locally.

Should I use recovery media when the board identity is unknown?

No. Do not select firmware or recovery media until the reported platform and exact manufacturer scope are established.

What should I include in a repair-identification request?

Include the exact model and cooling class, raw platform and firmware values, the complete board marking if safely visible, what happened before the fault, and the visible symptom. Redact credentials and unique network or device identifiers.