How we verify a coin before listing it

There are thousands of mineable coins in existence and most of them should never appear in a profitability table. Some are abandoned. Some report numbers that no independent source can reproduce. Some are outright fabrications built to attract hashrate to a chain nobody can exit. Listing a coin is a statement that its data can be trusted enough to base a mining decision on, so we treat listing as a verification problem, not a catalog problem.

This is what actually happens between "someone submits a coin" and "the coin appears on /coins".

Step 1: independent sources or nothing

The first rule of the pipeline is that no single source is ever authoritative. For every candidate coin we require at least two independent ways to observe the network, and "independent" is doing real work in that sentence.

A block explorer run by the coin's own team and an aggregator API that scrapes that same explorer are one source wearing two hats. If the explorer is wrong, compromised or simply frozen, both feeds agree on the same bad number and a naive cross-check passes. So we classify sources by provenance before comparing them:

• Direct chain access: a node we run ourselves, or an RPC endpoint we can query for raw chain data such as height, difficulty and block timestamps.
• First-party explorers: operated by the project, useful but assumed biased.
• Third-party aggregators: convenient, wide coverage, but they inherit every upstream error and add caching delays of their own.

Verification means agreement between sources from different classes. When a first-party explorer says the network hashrate is 40 TH/s and raw chain difficulty implies 4 TH/s, the explorer loses. Difficulty does not lie; marketing pages sometimes do.

Step 2: the numbers that must reconcile

For each candidate we reconcile a small set of hard values across sources over a multi-day observation window:

• Chain height and block times. Heights should track within seconds of each other, and observed block intervals should match the protocol target. Chronic slow blocks mean the network is losing hashrate or the difficulty algorithm is broken.
• Difficulty and implied hashrate. We recompute network hashrate from difficulty and block times ourselves rather than trusting reported figures.
• Block reward and emission schedule. The reward we use in profit math is read from actual coinbase transactions, not from a whitepaper that may be three halvings out of date.
• Price and market depth. A price that exists on one exchange with a few hundred dollars of daily volume is a quote, not a market. We record where the price comes from and how much could realistically be sold into it.

Every value carries a timestamp and a source identifier, because the next step depends on both.

Step 3: the confidence score

Cross-checked data feeds a confidence score, the same freshness and agreement machinery that powers the opportunity score you see in the mining calculator. Three things move it:

• Agreement: how closely independent sources match, weighted by how independent they really are.
• Freshness: how recently each source updated, penalized steeply as data ages.
• Stability: whether the values behave like a real network or jump around in ways that suggest a broken feed.

A coin cannot be listed until its confidence score holds above threshold for the full observation window. A project that looks perfect for two days and then goes dark for six hours restarts the clock. This filters out an entire category of coin: technically alive, operationally unreliable.

Step 4: a human looks at it

Automation catches inconsistency; it does not catch intent. Before anything goes live, a person reviews the file: who runs the exchanges the price comes from, whether the GitHub activity is real development or timestamp theater, whether the pool landscape is more than one pool operated by the founders, whether the chain has a history of deep reorgs. Boring findings are good findings. Anything interesting at this stage is usually a reason to decline.

Step 5: listing is not permanent

The same monitors that admitted a coin keep judging it. When a network stalls, when the last real exchange delists it, when confidence stays below threshold for weeks, the coin is flagged and eventually removed from active profitability rankings. Dead projects do not get to sit in a table next to living ones just because they qualified once.

The uncomfortable truth of mining data is that most errors flatter the coin. Overstated hashrate, stale optimistic prices, phantom rewards: they all push estimated profit up, never down. A verification pipeline is how we make sure that when a coin tops a profitability table, it earned the position with data, not with a broken feed.