Methodology
How SoloFury Block Info collects, attributes and verifies SHA-256 blocks. Every number on a Block Info page can be traced to a rule on this page and to a JSON endpoint of the API.
1. Data sources
All data comes from full nodes operated by SoloFury, one per chain. Pruned nodes keep only recent blocks, so the index starts at a fixed block for those chains and grows forward; blocks older than the start exist on the chain but are not in this dataset.
| Chain | Node software | Node type | Index starts at | Blocks indexed |
|---|---|---|---|---|
| Bitcoin (BTC) | Bitcoin Core 31.1.0 | pruned | block 962,827 · 2026-08-17 | 6,070 |
| Bitcoin Cash (BCH) | Bitcoin Cash Node 29.1.0 | pruned | block 880,998 · 2025-01-14 | 89,492 |
| Bitcoin II (BC2) | BitcoinII 31.1.0 | full | block 1 (complete chain) | 60,182 |
| Bitcoin Cash II (BCH2) | Bitcoin Cash II 27.0.2 | full | block 1 (complete chain) | 83,026 |
| eCash (XEC) | Bitcoin ABC 0.33.9 | pruned | block 661,841 · 2020-11-22 | 306,867 |
| DigiByte (DGB) | DigiByte Core 9.26.5 | pruned | block 21,903,011 · 2025-08-12 | 2,383,960 |
2. Indexing
A poller reads each node every minute and stores, for every block: height, hash, previous hash, time, difficulty, size, transaction count, the full coinbase transaction and its outputs. Before adding new blocks it re-reads the last 10 indexed hashes; if the node's chain differs, those blocks are rewritten (reorg handling). The index contains only blocks on the main chain as seen by our nodes; blocks that lost a reorg are not listed. The height URL of a block always shows the current main-chain block at that height.
3. Reward, subsidy and fees
Total reward is the sum of the coinbase outputs. Subsidy follows each chain's schedule (for DigiByte it is read from the node). Fees are total reward minus subsidy, i.e. the fees the miner actually claimed. Amounts are stored in base units (satoshi; 1/100 XEC for eCash) and shown in coins.
4. Coinbase output roles
Consensus: on eCash every block must pay a miner fund (32%) and a staking reward (10%); these are labeled as consensus outputs. Pool fee: only for SoloFury blocks, an output to one of SoloFury's published fee addresses (below). Miner: the largest remaining payable output. OP_RETURN: data outputs. Other: everything else, shown as it is.
5. Pool attribution (rules v2026.09)
Pools are identified from the text the miner writes in the coinbase. The confidence shown next to each pool name says how:
- Verified
- coinbase tag plus a pool-fee output on a published address (today: SoloFury)
- High
- an explicit rule matches a known pool tag (e.g. "/ViaBTC/")
- Medium
- a domain name in the tag (e.g. "example-pool.com")
- Low
- a bare tag without a known pool behind it; shown as "name (tag)"
- Unattributed miner
- no readable tag, or only the name of a generic mining software (Miningcore, yiimp, nodeStratum…), which identifies no one
Anyone can write another pool's tag in their own coinbase. Attribution from a tag is therefore evidence, not proof; only "verified" involves an on-chain check.
6. SoloFury pool-fee verification
For every SoloFury block on the main chain with a pool-fee output, the expected fee is computed from the coinbase and compared with the output actually paid. Expected fee = floor(basis × 1%), where the basis is subsidy + fees, or, on eCash, the miner share (total reward minus the consensus outputs). A block is verified when the paid output differs from the expected value by at most 1 base unit. eCash blocks between heights 948,319 and 960,174 (9 May – 30 July 2026) were mined during a 0% fee promotion and are shown as such. Full list: audit JSON · CSV.
| Chain | Current SoloFury fee address |
|---|---|
| BCH | bitcoincash:qqpcyj0nhfvrw33j6szd7tjx9g728vugkyupvvjpf0 |
| BC2 | bc1qmc0kuqjcsnzxmee3hvdvpamvfcwmups3th5wuq |
| BCH2 | bitcoincashii:qrkr7hpwa02newgkmszpur26kumz827vfv4lk0vdk5 |
| DGB | dgb1qvayz6xjf6l9suwz8pldya3s8jjj4ayqkjxl0gh |
| XEC | ecash:qq00atj7rjfk783zqu7p7a0ak2rnf4ygky58ctvv3d |
Addresses used in the first weeks of operation appear in the audit JSON next to each block.
7. Estimates
Network hashrate is estimated as difficulty × 232 / target block time (DigiByte: SHA-256 difficulty and 75 s, one fifth of the five-algorithm schedule). "Fast" means a block arrived in less than half the target time, "slow" in more than twice. On Bitcoin, the next difficulty change is estimated from the average block time of the current 2016-block epoch. The next-block time shown on chain pages is the average target time: waiting longer does not make the next block more likely. The probability of a given hashrate finding a block is computed by the solo mining odds calculator; expected revenue per TH/s by chain is on the profitability page.
8. Integrity checks
Every night each chain in the index is checked for continuity: every block must reference the hash of the block before it, with no missing heights. Last check: 2026-09-27 14:18 UTC — BTC OK · BCH OK · BC2 OK · BCH2 OK · XEC OK · DGB OK.
9. Limits
Blocks before the index start are not covered. Pool attribution can be wrong where tags are copied or ambiguous. Block Info has no transaction or address pages. Prices and USD values are not shown yet.
10. API and citation
Every page has a JSON counterpart under /api/blockinfo/, for example /api/blockinfo/bch/block/969283. To cite a block: SoloFury Block Info, Bitcoin Cash block 969,283, https://solofury.com/block-info/bch/block/969283/ (accessed YYYY-MM-DD).
Methodology version v2026.09 · page generated 2026-09-27 21:33 UTC