Results filter by Products, Guides, Miner DB, Glossary and Troubleshooting
Independent DCENT_OS Reviewer and Researcher Kit
DCENT_OS 0.9.0: exact-board Experimental status
beta20261002 has 29 exact-board status cards; 29 sets have retained or verified public static URLs. There are 17 raw SD images, 11 route-restricted archives and one BeagleBone developer payload. Only 13 raw-image rows have a lab SD route; 4 are inspection only while permissions conflict. Physical qualification is pending. The automated installer route is unavailable because its signed host does not resolve. Static file availability and installation permission are separate.
Historical July registry summary. This retained registry covers July records; use the current October release cards below for today's downloads.
Independent reviewers, miners and security researchers are invited to clone it, build it, flash only an exact guarded lane, break it and publish what fails. Positive coverage is not required. D-Central asks only for accurate hardware/build identification, safety and disclosure of supplied equipment.
Editorial independence
D-Central does not require a positive conclusion, talking points, a preview copy, approval rights or removal of unfavorable results.
Disclose any miner, control board, travel, engineering time or other support supplied by D-Central.
Embargoes apply only to responsibly disclosed security vulnerabilities and should be time-bounded by agreement.
D-Central may request factual corrections, but the reviewer controls the conclusion and publication.
What D-Central can provide
Independent DCENT_OS review inputs
Input
Scope
Disclosure requirement
Compatible test hardware
A spare exact S9 Zynq/XIL or S19j Pro Zynq/XIL unit/control board may be available case by case; availability is not promised.
Name the supplied hardware and who paid shipping.
Artifact record
Exact filename, SHA-256 list, signed package manifest, release key fingerprint and model evidence page.
Publish the digest and lane tested.
Source/build orientation
Repository map, open-source boundary, vendor-input boundary and no-hardware test path.
State whether you built the daemon, dashboard or a complete image.
Recovery preparation
Model-specific evidence page, public recovery guidance and preflight checklist.
Do not flash until recovery is proven on the test unit.
Measurement template
Public field schema for power, hashrate, thermals, pool evidence and stability.
Publish raw measurements and failures.
Minimum reproducibility checklist
Clone the public repository and record the commit.
Run the no-hardware tests and document every failure or excluded test.
Build the daemon/dashboard and distinguish that from building a bootable image.
Verify the vendor-boot-input boundary and all artifact signatures/checksums.
Identify the exact miner, hash boards, control board, PSU and recovery route.
Prove accepted pool shares; connected, enumerated or nonce flow is not enough.
Measure wall power, pool-side hashrate, J/TH, temperatures, fans, rejects and stability with raw data.
Capture network behavior and test authentication/update failure paths.
Perform and document recovery before treating the installation route as reproduced.
Stable project description for coverage
DCENT_OS is D-Central Technologies' GPL-3.0 open-source Bitcoin mining firmware for Bitmain Antminer ASIC miners.
Current publication: 20 exact-board Experimental artifact sets in beta20261002: 17 raw SD images, two route-restricted archives and one BeagleBone developer SD payload with no supported consumer installation path provided here. Their producer, media and runtime signatures were verified under the explicitly approved development authority. Each release card lists its exact controller, signed companions, host verification and recovery boundaries. Host key selection does not change miner runtime trust. Artifact availability is separate from physical boot, accepted shares, endurance, recovery and production qualification. Six cleaned source bundles provide 4,614 matching project files and scoped upstream source evidence; third-party kernel, boot and FPGA source correspondence and redistribution permission remain unverified. Development signing approval is not licensing clearance. Historical July registry records remain available separately.
Reviewer terms and evidence requirements reviewed 2026-08-29. No independent review is implied until a dated external report is linked from the evidence ledger.
Read a successful verification result before planning recovery
Use the S19 Pro Xilinx release row as this worked example. Its exact board target is am2-s19pro. The original signed raw image is dcentos-s19pro-sd.img: 219,152,384 bytes, SHA256 3e487b7b1aba93a9a38940aa82bbeeb4d6b0a175e506311faf79766855307b57. The standardized alias contains the same image bytes; use the original basename with the row’s matching sidecars.
Keep the image and its four required companion files together: dcentos-s19pro-sd.img, dcentos-s19pro-sd.img.sig, dcentos-s19pro-sd.img.manifest.json, dcentos-s19pro-sd.img.runtime-image.json and dcentos-s19pro-sd.img.runtime-image.sig. Download the additional source-closure and producer-result companions when following the full receipt review. Use the catalog’s existing cryptographic commands and host prerequisites, including the independently published approved-development-release.pub.pem. An archive-shipped key alone is not an independent trust decision.
A matching SHA256 establishes matching downloaded bytes. A successful signature check establishes verification under the selected public key. A successful exact-board host dry run evaluates the package and media contract without writing a card. Record those as separate results. The documented host path is dcent sdcard install with --board-target am2-s19pro, --payload dcentos-s19pro-sd.img, --release-version 0.9.0, --release-channel beta and --dry-run; follow the catalog’s scoped key-environment instructions rather than changing a system-wide production pin.
The media policy is external_media_boot, with the SD card required and nand_writes=false. Physical qualification remains pending. A host PASS does not establish cold boot, accepted pool shares, safe airflow, a demonstrated restore or another controller’s compatibility. The approved development key’s raw public value is 131d0f0830b9a4118fe2bfb0670babef628a9611aa186d05db081ce0d1599bec; its publication approval does not change runtime production trust.
When results disagree
Wrong digest or size: preserve expected and actual values and the exact URL; redownload the same row into a separate folder. Stop if the mismatch persists.
Matching digest, failed signature: check the original filename, matching sidecar and selected key. Record the precise failure; do not disable verification or replace production trust pins.
Cryptographic checks pass, host contract rejected: retain the diagnostic and compare the exact board target, version, channel and required companions. A related model name does not override a policy refusal.
Host checks pass, recovery unproven: report host-only verification and the missing preparation. Do not mark installation, recovery or mining as reproduced.
Prepare the recovery evidence separately
Before any hardware experiment, record the control-board identity, starting firmware, hashboards and PSU; identify the exact documented route and restore guidance. Keep recovery-input availability, backup availability and an actually demonstrated restore as separate fields. Document required original stock material and access before proceeding; do not substitute guessed boot files.
Counterexample: the BeagleBone S19j Pro tar is an SD payload, not a complete bootable raw image. It requires separately verified AM335x MLO, U-Boot, kernel and carrier DTB inputs. The BB3 developer payload has no supported consumer installation path. It provides no general first-install or NAND route. A verified tar cannot fill those missing boot requirements.
For a reproducible report, retain original filenames, expected and actual hashes, public-key identity, verifier version and complete host diagnostics. Published source companions have stated coverage; they do not prove complete vendor kernel/U-Boot/FPGA correspondence or redistribution permission.
