Hammer updates BC04 and BC08 pool compatibility
Source report: 2026-09-11 · Editorial analysis published: 2026-09-14
Official firmware releases address compatibility with some Bitcoin pools. The release notes do not promise a higher hashrate.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
Two confirmed firmware releases
The official HammerMiner GitHub repositories contain BC04-APP release V3.0.5-20260909, published on September 11, and BC08 release v1.0.3-20260908, published on September 10. Both release notes describe a fix for compatibility with some Bitcoin pools. The dates embedded in the tags differ from the publication timestamps. This article uses the publication date for the latest of the two releases and preserves the complete identifiers so owners can distinguish the files.
What the notes do and do not say
The manufacturer does not identify the affected pools in these short notes or publish a benchmark showing a hashrate increase. It would therefore be inaccurate to label the update an overclock, an efficiency improvement or a universal fix for rejected shares. Compatibility concerns the interaction between miner and pool. A working connection, accepted submissions and the pool’s observed hashrate should be checked separately; the local dashboard alone does not demonstrate successful crediting.
Choose the correct model package
Editorial operating guidance: first record the exact device model, installed version, pool endpoint, worker name and relevant settings. Use the release for the corresponding device and follow that model’s official update instructions. The BC04 and BC08 identifiers are different; similarity of release notes does not make their firmware interchangeable. The companion BC08 release is available in the manufacturer’s BC08 repository under tag v1.0.3-20260908. Do not infer support for other Hammer models from these two entries.
Check before and after under comparable conditions
Record an initial observation period with accepted and rejected submissions, reconnects, local hashrate and the pool’s reported rate. After the update and a settling period, repeat the observation using the same pool, worker, operating profile and approximately comparable duration. This is an editorial verification method, not a benchmark supplied by Hammer. Simultaneously changing the pool and frequency makes it difficult to determine which change affected the result. Keep timestamps so reconnects can be matched to logs.
Read rejection statistics carefully
For an illustrative sample of 1,000 submissions with 10 rejected, the simple rejection rate is 1%. This count alone does not identify the reason: delayed work, network interruptions and other conditions can require different investigation. Moreover, pool accounting may weight work by difficulty, so a share-count percentage need not equal the same percentage of lost revenue. A short interval with zero rejected submissions is useful evidence for that interval, but not proof that all possible compatibility cases have been resolved.
A practical update decision
Owners experiencing connection or submission problems have a concrete release to investigate. Owners without symptoms can assess the change against their normal maintenance procedure instead of assuming every new version increases earnings. Preserve settings and a recovery path supported by the manufacturer, and avoid interrupting an update in progress. The confirmed news is the publication of two compatibility fixes; ASIC.Tools has not run a physical BC04 or BC08 benchmark and does not claim a measured performance gain.
Make a useful support record
If symptoms remain, a concise support record should identify the device, exact firmware, pool endpoint, observation times and relevant log lines with secrets removed. Describe what the local interface showed and what the pool recorded, rather than writing only that mining is broken. Keep wallet or worker details only where actually needed by the support process; never include administrative passwords. This record helps distinguish a repeated connection failure from a display discrepancy or a rejected submission. It does not prove which component is responsible and should not be presented as a manufacturer-confirmed defect.
Source: HammerMiner / GitHub ↗
Mining calculator ↗
