DGB HASHRATE / STARTUP DUE DILIGENCE / JUNE 2026

DGB Hashrate Due Diligence for Startups — DigiByte Mining Verification

Startups evaluating DigiByte mining partnerships, DGB treasury strategies, or cooperative hashrate contracts face a specific due diligence problem: the aggregate DGB hashrate chart — the number most operators cite — does not verify any individual operator's contribution to the network. A startup that commits capital based on an aggregate hashrate screenshot has verified that the DigiByte network exists, not that the operator has any meaningful share of it. The DGB hashrate verification framework covers the four checks that produce a verifiable answer. This page covers what startup-specific due diligence on dgb mining looks like in practice.

Why DGB hashrate due diligence is harder than Bitcoin mining due diligence

Bitcoin has one proof-of-work algorithm — SHA256. A Bitcoin mining due diligence process verifies one hardware class, one difficulty track, and one pool address type. DigiByte has five simultaneous algorithms, each with independent difficulty adjustment under MultiShield, each requiring a different hardware class, each with a separate pool address namespace.

This means a DGB mining operator can be simultaneously correct about SHA256 hashrate and completely absent from Odocrypt — and cite the same aggregate chart as evidence of both. Startup due diligence that does not decompose the claim by algorithm is not verifying the relevant product. It is verifying that the DigiByte network exists and that the operator knows its aggregate hashrate.

Per-algorithm hashrate data is publicly available on DigiExplorer and CoinWarz. Per the DigiByte Foundation's MultiShield documentation, each algorithm adjusts difficulty independently every block — approximately every 15 seconds. A due diligence process that does not check all five algorithms has not verified the claim being made.

The DGB mining due diligence checklist for startups

  1. Identify the specific algorithm the operator claims to mine — SHA256, Scrypt, Skein, Qubit, or Odocrypt. If they cannot specify, the hardware and pool verification steps that follow are impossible.

  2. Request the pool name and the specific pool address tied to the declared hashrate allocation. Search that address on the pool's public statistics page. DigiHash, HashBros, and PoolBay all publish per-address data without registration.

  3. Verify hardware compatibility with the named algorithm. SHA256 and Scrypt require ASICs. Skein and Qubit require GPUs. Odocrypt requires GPU or FPGA hardware that can survive periodic algorithm forks — the last confirmed fork was 2023. ASIC hardware on Odocrypt is not a technical limitation; it is a factual incompatibility.

  4. Review the return projection for algorithm-specific difficulty assumptions. A projection using a single DGB difficulty figure is using one number where five are required. Request five separate difficulty curves, each updated at least monthly, each tied to a hardware efficiency ratio for the named algorithm.

  5. Audit exit terms for algorithm-specific hardware depreciation schedules. A GPU running Odocrypt has a different depreciation curve than an ASIC running SHA256. A contract with uniform depreciation across all algorithms has not been written by someone who understands the product.

The 2022 failure pattern and what it cost

In Q1 2022, three cooperative DGB mining operators suspended withdrawals within eight weeks of each other. DigiByte network hashrate had increased 340% between January 2021 and April 2022 — difficulty across all five algorithms rose proportionally. The operators' fixed return contracts did not reflect a single difficulty adjustment.

Post-mortem analysis showed that in each case, the capital raised was not deployed in mining hardware at the scale implied by the return projections. Referral deposit inflows substituted for mining yield. The aggregate DGB hashrate chart — real network data, publicly available — was the primary evidence cited in investor materials. None of the operators provided per-address pool records when requested.

The structural lesson: an operator who cites the DigiByte network's aggregate hashrate as evidence of their output has provided a number that does not change regardless of whether their hardware exists. The relevant evidence is a per-address hashrate reading on a named public pool. That reading either exists or it does not. If it does not exist within 24 hours of a written request, the due diligence answer is complete.

Further reading on Subsocket

— DGB hashrate chart guide — the four-point verification framework in full

— DGB hashrate red flags — the Q1 2022 collapse pattern, structural analysis

— Five-algorithm comparison — hardware classes, ASIC resistance, difficulty mechanics

— About Subsocket — what this site covers, data sources, and correction policy