DCENT_OS separates the Linux platform, the Rust mining engine, hardware-specific adapters and the local control surfaces so evidence for one miner or board is not silently generalized to another.
System map
Bitcoin pool (Stratum V1; V2 behind readiness gate)
│
▼
dcentrald (Rust)
┌──────────────┬────┼───────────┬──────────────┐
│ │ │ │ │
ASIC HAL Stratum Autotuner Thermal/PSU REST + WS + MCP
│ │
▼ ▼
Zynq / Amlogic / BeagleBone / CVITEK adapters Local dashboard
│
▼
BM1387 / BM1397 / BM1398 / BM1362 / BM1368 hash boards
Buildroot Linux
The industrial branch boots a small Buildroot Linux userspace. The open Buildroot external tree assembles the services and launches dcentrald; boot-critical vendor components remain a separately documented input boundary.
The Rust mining engine
DCENT_OS runtime modules and their evidence boundaries| Module | Responsibility | Evidence boundary |
| ASIC HAL and drivers | Chip detection, work dispatch, nonce decoding and board I/O | Per-model accepted-share or bring-up evidence |
| Stratum | Pool connections, share validation, failover and protocol state | V1 is the baseline; V2 is implemented behind a readiness gate with submit/accept soak still pending |
| Autotuner | Frequency and voltage-domain search within safety clamps | Source capability is not claimed as validated on every artifact |
| Thermal and PSU control | Fan PID, throttling, shutdown and PSU telemetry/bypass | Sensor and PSU behavior stays platform-specific |
| API and dashboard | Local REST/WebSocket telemetry, configuration and three-mode UI | Control actions require authenticated owner sessions on release images |
| MCP surface | Local-agent monitoring and guarded control tools | Read and write capabilities remain explicit; writes fail closed without owner authorization |
Why one architecture does not mean universal support
ChipID detection and shared connectors let the code select drivers across several generations. That is an architectural capability, not proof that every control-board/hash-board combination has a safe installation and recovery route. The public platform matrix remains the authority for each lane.
Control-board adapters
- Zynq: FPGA chain access through UIO and
/dev/mem, without a proprietary kernel module. - BeagleBone: serial UART hash-chain path through the S19j Pro I/O board; runtime evidence does not imply a general NAND install.
- Amlogic: serial chains plus sysfs PWM/GPIO; stock AMLCtrl ownership is an installation boundary.
- CVITEK: architecture analysis and runtime ownership are still in development; no executable public install route is claimed.
Read the code by subsystem
Start at dcentrald/, the Buildroot external tree, the dashboard, and the evidence matrix.
Architecture reviewed against the public repository on 2026-08-08.