STARTUP DUE DILIGENCE / UPDATED OCTOBER 2, 2026
DGB Hashrate Due Diligence for Startups — DigiByte Mining Verification
A startup due diligence checklist for DigiByte mining proposals: separate network data from operator evidence, verify pool and hardware claims, test assumptions, and review contract terms.
A startup considering a DigiByte mining contract needs evidence about a named operator, not just a chart of the whole network. A plain-language dgb overview can introduce the asset; it cannot verify who controls equipment, what it mines, or how revenue is calculated. This guide separates those questions into checks a technical, finance, and legal reviewer can document.
Separate network evidence from operator evidence
DigiByte's public chain and mining data can provide useful context, but the operator's dashboard is not an independent record of its own output. The official DigiByte Core repository and DigiByte project site describe the network and protocol. For a counterparty-specific claim, ask for dated evidence that can be matched across pool, hardware, wallet, and contract records.
| Claim | Evidence to request | Cross-check |
|---|---|---|
Network conditions | Dated chain or explorer data with metric definitions | Compare the same time range and named algorithm |
Operator hashrate | Pool name, worker identifiers, reporting window, and export or read-only view | Reconcile pool-side values with the contract's stated allocation |
Equipment | Make, model, serial or inventory record, hosting location, and ownership or lease terms | Check the named hardware is compatible with the declared algorithm |
Operating costs | Power rate, hosting invoice, maintenance terms, and uptime assumptions | Recalculate under changed power price and downtime |
Payouts | Pool statements, payout addresses, transaction IDs, fees, and dates | Match amounts and timestamps to the accounting ledger |
A diligence sequence for the first review
Collect evidence before modelling returns
- 1. Write each claim down
Split the proposal into network, operator, hardware, cost, payout, and legal claims. Ask for the unit, scope, source, and date behind every number.
- 2. Verify pool and worker records
Ask which pool and algorithm are involved, how worker identities map to the contract, and whether the pool permits a public view or a dated export. Note any evidence you cannot independently access.
- 3. Inspect the hardware path
Match equipment models to the declared workload. Request inventory, deployment or hosting evidence, maintenance arrangements, and a way to reconcile equipment uptime with pool reporting.
- 4. Rebuild the operating model
Separate expected coin production from fiat valuation. Recalculate with changed network difficulty, coin price, pool fees, power costs, outages, and hardware downtime. State each assumption.
- 5. Review control and exit terms
Confirm who controls pool accounts and payout addresses, what happens during downtime, how reporting is audited, how either side terminates, and what records are delivered at exit.
- 6. Document unresolved gaps
Assign an owner and deadline for missing evidence. Do not turn an unanswered diligence question into an assumed positive.
Terms that should be explicit in the contract
The algorithm, pool, worker or allocation identifiers, measurement unit, and exact definition of any hashrate commitment.
Reporting cadence, source records, audit access, and treatment of estimated or unavailable pool data.
Fees, power and hosting costs, maintenance responsibility, and how downtime affects billing or revenue allocation.
Payout schedule, destination-address control, transaction records, reconciliation process, and treatment of network or provider delays.
Termination rights, equipment ownership, transfer or removal costs, dispute process, and applicable jurisdictions.
Signals that call for more evidence
A fixed return projection, an aggregate network chart used as proof of one operator's contribution, missing pool identifiers, or refusal to provide dated records should pause the review. None proves misconduct on its own. Each means the claim is not yet supported by the evidence described, so the team should verify it or exclude it from the decision model. Have qualified finance and legal reviewers assess the contract, tax treatment, and counterparty risks for the startup's jurisdictions.
FAQ
Does a network hashrate chart prove a mining operator's output?
No. It is a network-level estimate. Ask for evidence tied to the operator, named pool, worker or allocation, and reporting window.
What if a pool does not publish worker data publicly?
Record that limitation and request an alternative such as a dated pool export, supervised read-only access, and payout records that can be reconciled. Label the evidence as provider-supplied if it cannot be independently queried.
Should projected DGB production be treated as guaranteed?
No. Model it as an estimate with explicit difficulty, uptime, fee, power, and price assumptions. Stress-test changes and keep coin production separate from its fiat valuation.
Who should review a mining partnership?
Technical reviewers can test data and equipment claims; finance reviewers can rebuild the model; legal reviewers can assess ownership, liabilities, termination, tax, and jurisdiction-specific obligations.
Sources and related guides
Start with the primary DigiByte Core code and documentation and DigiByte project site. For implementation details, see the builder's guide; for presenting public data, see the WordPress guide. Find more Subsocket articles.