ROI ASIC · Academy
From One ASIC Canary to a Fleet Decision
A canary is a bounded test on a named hardware cohort, not a miniature proof for the whole fleet. Progress only when the test has comparable before/after evidence, no unresolved stop condition and a written GO/HOLD/STOP decision.
Working method
- Define the cohort before choosing the canary: exact model, variant, board, PSU, cooling class, site and current firmware state.
- Choose a unit representative of that cohort, while recording any reason it is not representative. Keep a recovery route and owner ready.
- Freeze the baseline using the same sources planned for after-change comparison: wall power, pool-side work, availability, cooling and errors.
- Change one controlled factor. Observe long enough for the stated risk and process; do not invent a universal threshold.
- GO only for the named cohort and next bounded batch. HOLD when evidence is incomplete. STOP on a safety, identity, recovery or material operational failure.
Work through a situation
Learning scenario — not a reported customer result.
Imagine a hypothetical fleet in which several machines share a familiar product-family name, while their control boards or cooling arrangements differ. A successful trial on one machine does not erase those differences. Before calling that machine a canary, define the group it is intended to represent and list the exclusions.
Keep the before-and-after comparison tied to that group, the exact build and the site's stated conditions. If the trial produces incomplete pool observations, an unexplained hardware change or a missing recovery dependency, do not turn a favorable-looking power figure into permission to expand. Record HOLD or STOP under the agreed rules and explain which evidence is missing.
If all required conditions are met, GO should name the next bounded group, not the entire fleet. The next group still needs its own observation and decision. This approach makes a useful distinction between an installation that worked on one device and a deployment decision that others can review.
It also prevents a neat spreadsheet from silently becoming a claim about hardware or operating conditions that were never tested.
Limits and stop conditions
- One canary cannot represent different boards, cooling classes or electrical environments.
- A calculated improvement is not measured fleet value.
- Scaling is a new decision with a rollback boundary, not an automatic continuation of installation.
Reusable artifact
| # | Field | Checked | Evidence / note |
|---|---|---|---|
| 1 | Cohort definition and exclusions | □ | |
| 2 | Canary identity and baseline | □ | |
| 3 | Changed factor and exact route | □ | |
| 4 | Before/after evidence with matching windows | □ | |
| 5 | GO/HOLD/STOP owner, rationale and next batch boundary | □ |
Copy this structure into a change record; never place passwords, keys or private access details in it.
Terms used in this guide
- Canary
- A deliberately bounded initial trial used to inform a later deployment decision.
- Cohort
- The specifically defined group of devices and conditions to which a test is intended to apply.
- Acceptance condition
- A requirement that must be checked before a particular progression decision is allowed.
Check your understanding
These questions check understanding. They do not approve an installation or certify a result.
Does a shared product-family name define a sufficiently uniform test group?
Show answer
No. Relevant hardware, firmware state, cooling and site conditions also matter.
What should GO authorize?
Show answer
Only the explicitly named next bounded group under the agreed acceptance conditions.
Can a favorable power result replace missing recovery evidence?
Show answer
No. A required recovery condition remains required.
Primary sources
- BITMAIN — Online Upgrade Tutorial (updated 2026-03-03) Reviewed 2026-09-10
- BITMAIN — Product Warranty Reviewed 2026-09-10