The short answer
Every Zcash block contains a coinbase transaction created by the miner who found it. Mining pools typically leave identifiable fingerprints in this transaction: a readable name, a binary signature, or a structural pattern unique to their software. We search for these fingerprints using five attribution methods, each explained below with real examples from the Zcash blockchain.
What's in a coinbase transaction?
The coinbase transaction is the first transaction in every block. Unlike normal transactions that spend existing coins, the coinbase transaction creates new ZEC. This is how miners receive their block reward.
The coinbase transaction includes a free-form data field called the scriptSig. The only requirement is that it starts with the block height (a rule called BIP34). After that, the miner can embed whatever they want: a pool name, a message, random bytes, or nothing at all.
This free-form data is the foundation of pool attribution. Most pools use it to advertise their identity, and even pools that don't leave an explicit tag often produce a distinctive pattern. You can inspect the coinbase data yourself on any block detail page in the "Coinbase" section.
Method 1: Coinbase tags
The most common identification method. Many pools embed a human-readable ASCII string in the coinbase scriptSig, signing every block they mine with their name.
Examples of tags found on the Zcash blockchain:
/ViaBTC/Hello world!/Antpool,/Antpool/2miners.comPoolin,poolin.com/flypool/Mining-Dutch
When we find a recognized tag in the coinbase text, the confidence is very high. The pool explicitly signed the block, though any miner could technically include another pool's tag. This is the same technique Bitcoin block explorers use.
Method 2: Coinbase signatures
Some pools embed a signature that isn't readable ASCII text. Instead, it's a binary pattern buried in the raw hex data of the coinbase transaction. These signatures don't show up when decoding the coinbase as text. They require hex-level analysis.
For example, a pool might encode its brand name in non-ASCII characters (such as Chinese, Cyrillic, or emoji) as raw UTF-8 bytes in the coinbase data:
These multi-byte signatures can appear in 100% of blocks from a given pool's addresses and in 0% of blocks from any other pool, making them just as reliable as a text tag.
Signatures like this are also valuable for tracking pools across address changes. Even when a pool rotates to a new payout address, the hex signature may still be present, confirming continuity.
Method 3: Software fingerprinting
Even when a pool doesn't embed an explicit tag or signature, their mining software can produce structurally distinctive coinbase data. By analyzing the hex structure of confirmed blocks from a known pool, we can derive a fingerprint: a pattern in the coinbase bytes that's unique to that pool's software.
For example, a pool might originally tag blocks with a readable name. If they later remove the tag, a structural remnant may persist, such as a trailing byte that appears in 100% of that pool's blocks and 0% of blocks from any other pool.
By following such fingerprints across multiple address changes, it's possible to trace a pool's full chain of addresses over several years, even when only the earliest blocks carried a readable tag.
Fingerprint-based attribution is high confidence when the pattern is exclusive to one pool. We validate exclusivity by checking whether any other addresses on the network share the same pattern.
Method 4: Address handoff
Mining pools periodically rotate their payout addresses. When this happens, one address stops producing blocks at the exact same time a new address begins, often within minutes or even a single block height.
To confirm a handoff, we plot the combined monthly block share of both addresses through the transition period. If the combined share is continuous with no discontinuity, that's strong evidence that both addresses belong to the same pool.
In the example above, Address A (a known pool) stops mining in June. Address B (untagged) starts at the exact same time. Their combined network share is smooth through the transition: no spike, no drop, just a seamless continuation.
This method has been used to track several major pools through address rotations. The confidence is high when the timing is tight (same day, single-digit block gap) and the share continuity is clean.
Method 5: On-chain analysis
The final method combines two signals: on-chain funding traces and solrate correlation.
On-chain funding traces look at the flow of ZEC between addresses on the public blockchain. Mining pools need to fund their operations, and those funding transactions are visible to anyone. When a known pool's address sends a significant amount of ZEC directly to an unknown mining address, it suggests an operational relationship between the two. A pool is unlikely to send large sums to an address it doesn't control, so a direct funding link is a meaningful signal that both addresses belong to the same operator.
Solrate correlation compares two numbers: the solrate a pool publicly reports (for example, via their API or website) and the solrate implied by an unknown address's share of mined blocks. If a known pool reports a substantial solrate but has no identifiable blocks during a period, and an unknown address is mining at a nearly identical rate during that same period, it suggests the unknown address may belong to that pool. This is especially telling when the numbers are close enough to fall within normal day-to-day variance.
Neither signal is conclusive on its own. A funding transaction could have other explanations, and solrate correlation is inherently approximate. But when both signals point to the same pool, they reinforce each other. This is the most circumstantial method and is never used as the sole basis for attribution. It serves as supporting evidence, helping increase confidence when other indicators (like timing or fingerprint similarities) are present but not conclusive on their own.
For example, a pool may tag blocks with readable coinbase text for an extended period, then stop. Months later, an untagged address begins mining with no coinbase tags, no hex signatures, and a gap too long to be a clean address handoff. But on-chain transactions totaling a significant amount of ZEC link the old address directly to the new one:
When the funding trace and solrate correlation both point to the same pool, we attribute those blocks with medium confidence. The two signals together are stronger than either alone, but because both involve inference rather than a direct identifier, the confidence remains below coinbase tags or fingerprints.
Confidence and coverage
Not all attribution methods carry the same weight. We group them into three confidence tiers:
Most blocks are attributed through coinbase tags and signatures alone. The other methods primarily extend coverage to blocks that would otherwise show as unknown by tracking pools across address rotations or linking untagged addresses back to known operators. When the evidence doesn't meet at least the medium confidence threshold, the block stays unattributed rather than risk a misattribution.
Blocks we can't attribute to any pool appear as "Unknown" on the Pools page. These include solo miners, pools that don't leave any identifying marks, and historical blocks from before pool tagging became standard practice. Attribution is an ongoing process, and coverage continues to improve as new patterns are identified.
See it yourself
Everything described here is transparent and verifiable on the explorer:
- Pools page: All identified pools, their block counts, and network share over different time periods.
- Pool detail pages: Click any pool to see its known coinbase tags, payout addresses, historical dominance, and individual blocks.
- Block detail pages: Click any block on the Blocks page to see the raw coinbase text, hex data, payout address, and which pool was identified.
If you have questions about a specific attribution or notice something that looks off, let us know on the Contact page.