Most mining pools ask for something very simple: that you trust a number on their dashboard. How much hashrate they claim to have, how many blocks they claim to have found, how much they claim to have paid you. That trust rests entirely on the pool operator being honest, and mining history is full of pools that were not. OwnBlock was built on the opposite premise: the fewer claims you have to take on faith, the better. This article walks through the four layers of transparency and verification you can use today, without asking permission or credentials, to check the pool's behaviour for yourself: the coinbase payout design, the public block history, the read-only API, and the coin-specific audit mechanisms.
Layer One: Payouts Happen in the Coinbase, Not in an Internal Ledger
The most important difference between OwnBlock and a traditional deferred-payment pool is not a marketing slogan, it is a verifiable architectural decision. OwnBlock does not hold an internal balance that it later transfers to miners through ordinary transactions indistinguishable from the rest of network activity. Instead, the miner's address is encoded directly into the coinbase transaction (Bitcoin and Bitcoin Cash) or the miner tx (Monero) at the moment the candidate block is built. Once that candidate block includes the miner's output and the block is accepted by the network, there is no subsequent custodial phase in which OwnBlock has to make, approve or delay the payment: the output is included in the corresponding coinbase transaction or miner tx and cryptographically committed to by the block's own Merkle root, so any third party can verify its existence directly from the chain data. If you want the exact mechanics, outputs, scriptPubKey, one-time keys in Monero, our guide on the coinbase transaction explained covers the full technical detail.
Layer Two: The History Does Not Show Only the Successful Blocks
Each pool's blocks page (/pools/xmr/blocks, /pools/btc/blocks, /pools/bch/blocks) lists every block the pool has proposed to the network, along with its status: accepted, confirmed after the maturation period, orphaned or rejected. Each entry links to its own detail page with the block height, hash, reward and, where applicable, the coinbase transaction or miner tx hash. This is deliberate: a pool that only showed its winning blocks would be presenting an edited version of its own history. Accepted blocks can be cross-checked directly against public explorers or your own node. Orphaned blocks may have been valid but ended up outside the main chain; rejected blocks, by contrast, never made it into the chain at all. Because of that, not all of them will be available on public explorers, and they remain in OwnBlock's history too, so the pool's behaviour is not limited to its successful outcomes alone.
Layer Three: A Read-Only API Instead of a Black Box
All of the information above is also available through OwnBlock's public API: GET endpoints, no authentication or API key required, returning consistent JSON for XMR, BTC and BCH. The stats endpoints (/xmr/stats, /btc/stats, /bch/stats) expose pool hashrate, network hashrate, difficulty and the last block found; the history endpoints (/xmr/blocks, /btc/blocks, /bch/blocks) return paginated lists of blocks with their maturity status. This makes OwnBlock observable, machine-readable and auditable, and lets you automate consistency checks between what the API reports and what the interface itself shows. But it is worth being precise here: an API run by OwnBlock and an interface run by OwnBlock most likely share the same backend, so checking one against the other is not, on its own, independent verification. For data that is verifiable on-chain, that independence comes when a third party cross-checks the API's information against their own node or a block explorer with no relation to OwnBlock. Internal metrics such as the pool's estimated hashrate still depend on information produced by the system itself.
Layer Four: Coin-Specific Audit Mechanisms
Each supported coin adds its own form of audit. For Monero, OwnBlock publishes via the API the secret view key (also called the private view key) of the wallet set aside for auditing. Together with the public address, this lets anyone build a view-only wallet and independently identify the outputs received by that wallet, without ever holding the secret spend key or any ability to spend the funds; a view-only wallet does not by itself give a complete picture of subsequent spending, but it is enough to confirm what came in. That wallet is not a custodial balance for miners: it only ever receives the pool fee, so every block OwnBlock finds produces exactly one entry in it. Anyone scanning it with the published view key can independently count the blocks found and cross-check that figure against the pool's public history, without depending on OwnBlock reporting it correctly. As an external verification not operated by OwnBlock, P2Pool Observer currently lists OwnBlock as "Verified with view wallet keys" and uses the published address and secret view key to directly verify the coinbase outputs received by the pool wallet. That deliberate loss of privacy over one specific wallet's incoming activity is precisely what enables the audit, without ever compromising spending ability: it is a design choice, not an oversight. For Bitcoin and Bitcoin Cash, every block mined by OwnBlock carries the /ownblock/ identifier in the coinbase data, verifiable directly from the block's raw data and visible on explorers that expose the coinbase script. That identifier is not a cryptographic signature, any other miner could technically include the same string in their own coinbase, but it does let you identify directly on-chain the blocks carrying OwnBlock's marker, without depending on the history published by the site itself.
What This Transparency Does Not Guarantee
None of these four layers changes the statistical variance of solo mining or speeds up reward maturity: BTC and BCH keep a coinbase maturity of 100 blocks, while in Monero the miner transaction's reward stays locked for 60 blocks. Nor do they replace checking your own specific payout, which is a separate and considerably simpler step, because the payout goes straight to your own address. If you want that exact check for Monero, with concrete commands, we have a dedicated guide on how to verify a Monero coinbase payout, step by step.
Verifiable by Design, Not by Promise
Real transparency is not saying "trust us" more emphatically, it is no longer needing that sentence at all. Check OwnBlock's public API, review the block history for Monero, Bitcoin or Bitcoin Cash, and cross-check any block against an independent explorer. The design is meant to let you do this yourself, at any time, without asking anyone for access.