DCENT_OS for Avalon (Canaan)
Every Antminer owner can choose between five aftermarket firmwares. An Avalon owner can choose none of them: Braiins OS+, VNish, LuxOS, ePIC and Hiveon each publish a supported-models list, and not one includes Canaan hardware Verified 2026-08-21. DCENT_OS is the fully open, GPL-3.0 firmware project being built to end that — in the open, with every milestone published as dated evidence, and with the same honesty ladder that carried DCENT_OS from zero to accepted pool shares on Antminer and Bitaxe-class hardware.
Why an open firmware for Avalon matters
Canaan deserves credit before anything else: it open-sources more of its firmware than any other major ASIC maker — roughly two dozen public repositories, including the complete Avalon_Nano3s home-miner firmware tree and its cgminer lineage Verified — public GitHub. That openness is exactly why the Avalon line is the most approachable custom-firmware target in mining, and why a community scene is already forming around the K230-based home miners — jailbreaks, third-party builds, overclocking guides. What that scene does not yet have is a fully open, GPL-3.0 operating system built for the whole line. That is the gap DCENT_OS is filling Supported — no other GPL-3.0 firmware project targeting Canaan was found as of 2026-08-21.
The sovereignty argument is the same one that drives everything we build: a miner whose firmware you cannot read, rebuild or replace is a machine you operate on someone else’s terms. DCENT_OS treats Avalon as a first-class platform target — the public repository commits to that structure openly rather than hiding it — and this page tracks the distance between commitment and proof without blurring the two.
What is proven today
Each row below is something that has actually happened, labelled by the strength of its evidence. Nothing weaker than the label appears in the row.
| Milestone | Evidence | What it means — and what it does not |
|---|---|---|
| DCENT userspace first light on a real Nano 3 | Experimental — real hardware, 2026-08-21 | A real Avalon Nano 3 on our bench booted a locally rebuilt root filesystem under Canaan’s own factory boot chain (SPL, U-Boot, Linux 5.10.4 on the Kendryte K230), exposed key-only SSH, and coexisted cleanly with the stock software. Canaan’s btcminer still owned the hashing throughout. DCENT_OS runs on the box; DCENT_OS does not yet mine the box. |
| K230 flashing stack | Verified — desk | Our tooling parses, verifies and assembles Canaan .kdimg system images and speaks the K230’s USB flash protocol end-to-end, with a capacity gate and a dry-run mode, bundling Canaan’s official MIT-licensed loader. Proven against real images on the desk. It is engineering capability we hold — not a download, and not a procedure offered to readers. |
| First DCENT system images assembled | Verified — desk | Complete first-light .kdimg images for the Nano 3 and Nano 3S, built from the public Kendryte K230 SDK and Buildroot with our Rust daemon embedded, every checksum verified by our own parser. Built and verified on the desk; deliberately not published. |
| Clean-room A3197S driver skeleton | Verified — desk; fails closed by design | The GPL-3.0 driver that will let DCENT_OS speak to the A3197S hash chips (Nano 3S; the Avalon Q’s silicon is the same family) is scaffolded clean-room. Its production constructor fails closed: until genuine captured bus bytes exist, it cannot even be constructed. That is an honesty feature — this project does not pretend to speak a protocol it has not captured. |
| Control-protocol primitives host-tested | Verified — desk | Canaan’s mm_pkg control codec (the 268-byte message ABI the Nano 3’s daemon speaks), AUP packaging and ascset operations are implemented and pass host-side tests. |
What is not yet
No mining ownership. On the one machine where DCENT_OS userspace has run, Canaan’s stock btcminer still manages the hash boards. In the public repository’s own words: “No accepted-share proof exists yet for DCENT_OS on Avalon hardware.” Verified — public repo
No public image. The images that exist are desk artifacts. Nothing is downloadable, and the repository says so plainly: “Do not treat this directory as installable firmware.”
No install route. There is no DCENT_OS procedure for putting anything on a Nano 3, Nano 3S or Avalon Q, and none will be published before the evidence exists.
When any of this changes, it changes in the public repository first and on this page next, with the same evidence ladder the Antminer and ESP platforms use: upload ≠ mined, connected ≠ mining, partial ≠ proven. A milestone earns its label or it does not get the label.
Why there is no public image yet
Honest answer, not a shrug: a license gate and a discipline gate.
Canaan’s real-time mining core for the current Avalon line is licensed BUSL-1.1 — source-available to study, not free to redistribute Verified — public license text. A public DCENT_OS image that shipped it would violate that license, so we will not ship one. That leaves two honest exits, and we are walking the first while keeping the second open:
- The clean-room driver — replace the licensed mining core entirely with our GPL-3.0 A3197S driver, built from captured bytes off hardware we own. This is the default path, and it is why the driver skeleton fails closed until those captures exist: clean-room means capture, then implement — never guess, never copy.
- A redistribution agreement with Canaan — a company that already open-sources more than any of its competitors. That door is not closed.
Until one of those lands, Avalon work stays lab-internal. That is what “in development” means on this page — not a euphemism, a boundary.
Per-model status — Nano 3, Nano 3S, Avalon Q
| Model | Hardware | DCENT_OS today | The next gate |
|---|---|---|---|
| Avalon Nano 3 | 4 TH/s · 140 W · Kendryte K230D Verified | In development — furthest along. DCENT userspace first light on a real unit (2026-08-21): our rebuilt root filesystem booted under the factory boot chain with key-only SSH, stock stack intact. Canaan’s btcminer still owns the hashing. Experimental |
A DCENT daemon-start proof that does not touch hardware ownership — validated coexistence before anything else. |
| Avalon Nano 3S | 6 TH/s · 140 W · 12× A3197S · K230D Verified | In development. A desk-built first-light image exists, and the clean-room A3197S driver skeleton targets exactly this machine’s chips. Verified — desk | Captured A3197S bus bytes from bench hardware — the fail-closed driver cannot be built without them, on purpose. |
| Avalon Q | ~90 TH/s · 1,674 W · A3225 (A3197S-class) · K230 Supported | In development. The Q rides the same K230 platform work as the home line — one SoC generation, one boot medium, one image format — so home-line progress is Q progress. Supported | A bench unit for partition-map validation, then the same clean-room driver work as the Nano 3S. |
| Avalon Mini 3 | ~37 TH/s · K230 Supported | In development — same K230 family path as the Nano line. A free community firmware already exists for this model from another project; we credit it rather than compete with silence. | Follows the Nano 3/3S bring-up. |
One boundary worth stating: the older K210-generation industrial Avalons run FreeRTOS with no Linux underneath, so a DCENT_OS system will never “install” there — fleet management and monitoring are the honest ceiling for those machines Verified.
Follow the work — or accelerate it
Every milestone above landed as a dated record, and the next ones will too. If you want Avalon owners to have what Antminer owners already have:
- Watch the repository. The DCENT_OS source is GPL-3.0 end to end; the Avalon directory is where status changes first.
- Contribute hardware or captures. The bottleneck is not code — it is captured bytes. Bench hardware and protocol captures from machines you own move this roadmap more than anything else; CONTRIBUTING.md explains how.
- Run the hardware. We stock and repair the machines this work targets — the Avalon Nano 3 is available from our Montreal shop, and every unit in the field is one more reason to finish.
Running stock firmware in the meantime is the right call — keep it current with our Avalon firmware update guide.