How a Bitcoin mining pool actually works: from share to payout

The standard explanation goes like this: miners combine their hashrate, find a block together, and split the reward. Nothing in that sentence is false, and nothing useful follows from it either. It does not tell you why you get paid on days the pool finds no blocks. It does not explain why the dashboard reports a different hashrate than your machine. It does not explain where 78% luck comes from, or why that number sometimes has nothing to do with your wallet.

What follows is the whole chain: what physically leaves your machine, how it gets counted, what it turns into, and at what point it becomes a transaction on your address. No lottery ticket metaphors.

POOL BTC is not a pool. We compare other operators' terms and work out what they cost a miner, so there is no operator being sold here and none being accused. Only mechanics, and arithmetic you can redo yourself.

Six things that matter

1. A share and a block are the same object. Only the height of the bar differs.
2. The pool assigns you a personal, easy bar so it can see your work every few seconds instead of once a century.
3. The pool builds the block, not you. Your hardware iterates numbers inside a header that arrived finished.
4. A payout scheme is a rule about who carries the risk of bad luck: you or the operator.
5. The fee comes off the gross reward, so in absolute terms it scales with price and with your hashrate.
6. Luck is a statistic, not operator behavior. On FPPS it never touches your payout at all.

What is a share, and how does it differ from a valid block?

A share is a block header whose hash landed below an easy target the pool assigned to you personally. A block is the same header whose hash landed below the target for the entire network. Only the height of the bar differs: the work, the data format and the validation are identical. Any share that happens to clear the network target becomes a valid block automatically.

A Bitcoin block header is 80 bytes and holds six fields: version, previous block hash, Merkle root, timestamp, nBits, and nonce. nBits is a compact encoding of the current network target, and it expands into the 256 bit number that the double SHA-256 of the header has to come in under.

Your ASIC takes that header and changes what it is allowed to change: the nonce (4 bytes), extranonce2 (the pool sets its length at connection time, and it feeds into the Merkle root through the coinbase transaction) and, if pool and firmware both support version rolling, some bits of the version field. Each candidate header gets hashed twice and compared against the target.

The pool checks two targets on every submission. The incoming share is compared against your personal target (clears it: counted into your accounting) and against the network target (clears that too: the pool publishes a block immediately). There is no separate act of "searching for a block." A block is a byproduct of the ordinary share stream.

One non-obvious consequence: a pool cannot hide a block it found without discarding the share itself. The coinbase transaction in its template carries the pool's own addresses and tag, and any block built from that template shows up in explorers under the same marker. The hands-on procedure for checking this is in our piece on verifying that a pool pays fairly.

By POOL BTC's calculation, at a network difficulty of 127,450,789,715,843 and a share difficulty of 65,536, one block takes about 1.94 billion shares on average. That is not an order of magnitude estimate but a straight division: network difficulty over share difficulty, because both are expressed in the same unit of expected work.

What is share difficulty, and why does the pool tune it to the machine (vardiff)?

Share difficulty is a multiplier saying how much easier your assigned target is than Bitcoin's base target. At difficulty 1 a share takes 2^32 hashes on average, roughly 4.295 billion. At difficulty 65,536 it takes 65,536 times that. The pool moves this number so that your stream of submissions stays convenient to account for.

The tuning mechanism is called vardiff, for variable difficulty. The pool watches how often you submit and raises or lowers your difficulty, aiming at a comfortable interval between shares. Set it too low and a large farm floods the server with traffic. Set it too high and a small machine's statistics turn noisy: if a share goes out once every two minutes, the hourly hashrate chart will swing by tens of percent on randomness alone.

By POOL BTC's calculation, a 100 TH/s machine at share difficulty 65,536 submits about 21.3 shares per minute, one roughly every 2.8 seconds. The arithmetic: 100 TH/s is 10^14 hashes per second, divided by 65,536 × 2^32 = 2.815 × 10^14 expected hashes per share, which gives 0.355 shares per second.

The same machine at different share difficulties:

And at a fixed difficulty of 65,536, across hashrates:

The thing worth taking away: share difficulty does not affect your income. It affects how fast the pool's estimate converges on your real hashrate. Double the difficulty and you send half as many shares of twice the weight. The product is unchanged.

Who builds the block template, and what goes into a block?

Under classic Stratum V1 the pool builds the entire template. It runs its own Bitcoin node, picks transactions out of the mempool, constructs a coinbase transaction paying its own addresses, and computes the Merkle tree. What reaches the miner is not a transaction list but a set of Merkle branches plus the two halves of the coinbase. The miner physically cannot select or refuse a transaction.

The mining.notify message that distributes work carries a job id, the previous block hash, both halves of the coinbase transaction, the Merkle branch list, version, nBits, time, and a clean_jobs flag. The miner inserts its extranonce2 between the coinbase halves, recomputes the Merkle root from the branches, and assembles the header.

That clean_jobs flag explains half of what looks strange in miner logs. When a new block appears on the network, the pool pushes a fresh job with clean_jobs set to true, and every bit of work on the previous job is worthless from that instant. Shares submitted afterwards against the old job come back rejected as stale.

What is actually inside the block: the coinbase transaction (the subsidy plus the sum of fees from every included transaction, with the subsidy at 3.125 BTC as of 24.09.2026) and a set of mempool transactions, usually sorted by fee per virtual byte. The fee portion of total block reward is small right now. Per mempool.space on 08.09.2026 it was 0.66% across the last 4,320 blocks and 0.57% across the last 144, and over the month the figure stayed between 0.66% and 0.73%. Other aggregators looking at single day windows report 0.40% to 0.56%, because they use a different denominator. There is no single correct number here, only a number with a stated window and source.

The one part of the protocol that takes template construction away from the pool is Job Declaration, part of Stratum V2. It runs in production at a handful of pools, and it should not be confused with a pool announcing that it "supports Stratum V2." The three separate adoption numbers behind those announcements are pulled apart in our piece on Stratum V2 and who picks the transactions.

How does the pool measure a miner's contribution and turn it into a payout?

The pool keeps a log of accepted shares with their weights, tied to your worker. At settlement time (the end of the daily period for the PPS family, the moment a block is found for PPLNS) it computes your portion by its formula, subtracts the fee, credits an internal balance, and sends a transaction once that balance clears the payout threshold.

The full path of one share, from ASIC to coins in your wallet:

1. The pool sends mining.notify with a job and your worker's current difficulty.
2. The ASIC iterates nonce, extranonce2 and version bits until the double SHA-256 of the header lands below your target.
3. The ASIC sends mining.submit: job id, extranonce2, time, nonce.
4. The pool checks that the job is current, that the share is not a duplicate, and that the hash really is below your target. It compares against the network target at the same time.
5. The accepted share goes into the log with a weight equal to its difficulty.
6. The pool credits your portion: either a fixed rate per share or a slice of a found block's reward, depending on the scheme.
7. The pool fee comes off that credit, calculated on the gross amount.
8. What remains lands on the internal balance, usually shown as "unpaid" in the dashboard.
9. Once the balance clears the threshold, the pool builds a transaction, deducts the network fee according to its own policy, and sends it to your address.
10. After confirmations the amount is finally yours. Until that moment it is an operator's liability, not your money.

Steps nine and ten deserve a pause. Between "credited" and "arrived" sits the payout threshold, and at small hashrate that threshold turns into a waiting period.

By POOL BTC's calculation, a 100 TH/s machine at a network hashrate of 930.73 EH/s and a 3.125 BTC subsidy earns 0.00004835 BTC per day in gross subsidy (network parameters: mempool.space, snapshot of 08.09.2026). Adding the 0.66% fee portion brings it to 0.00004867 BTC, and after a 2% pool fee 0.0000477 BTC per day remains. Against the 0.001 BTC threshold published by F2Pool, AntPool and Luxor, the first payout arrives around day 21 of uninterrupted running. Against Ocean's threshold, listed in secondary sources as 0.01048576 BTC, the wait would be roughly 220 days.

This is not a dig at Ocean, which also pays over Lightning with no threshold. It illustrates that a payout threshold means one thing for a single machine and something else entirely for a 10 PH/s farm. You can match the threshold to your own hashrate and work out the interval between payouts in the POOL BTC calculator.

How do PPS, FPPS, PPLNS and SOLO differ mechanically rather than in marketing?

A payout scheme answers exactly one question: who carries the risk that blocks arrive later than expected. Under PPS and FPPS the operator takes that risk and sells you predictability through a higher fee. Under PPLNS and TIDES the risk stays with the miners and gets spread across a window of shares. Under SOLO it is entirely yours, with no averaging whatsoever.

The mechanical difference shows up in two places. First, under FPPS the per share rate is known in advance, so the daily credit has to be flat at constant hashrate, and any step in that chart is either a network difficulty change or a problem on your side. Second, a PPLNS window is defined in units of work rather than time, so as network difficulty climbs the window shrinks in hours on its own.

How operators actually word their windows varies more than people assume. ViaBTC officially says "the past 5 difficulty rounds." Ocean documents its window as eight times the block's difficulty worth of shares. AntPool and F2Pool refer to "the last N difficulty rounds" without publishing N. Braiins has run BTC on FPPS only since December 2023 and offers no PPLNS style scheme at all.

The formulas for every scheme, along with what happens to your shares when you leave a pool, are covered in our dedicated piece on payout schemes. The risk split above is the part that matters here.

Where does the pool fee come from and what does it cover?

The pool fee is a percentage the operator withholds from the gross reward before distribution. It pays for Bitcoin nodes and stratum servers across several regions, an on call team, the variance risk the operator absorbs under PPS schemes, and the settlement infrastructure. Rates at large pools sit somewhere between 1% and 4%, and comparing them across schemes directly does not work.

The detail people skip: the fee comes off gross credit, not off profit and not off what remains after electricity. So the same percentage means different absolute money at different prices and different hashrates, and this is also why PPS schemes charge more. Baked into that percentage is the price of the operator guaranteeing your payout in a bad week.

What is confirmed about specific pools as of this snapshot:

By POOL BTC's calculation, the gap between a 2% and a 4% fee on a 100 TH/s machine is 0.00000097 BTC per day, about 0.000355 BTC over a year. That number looks trivial right up until you multiply by machine count: across a farm of 100 identical ASICs, the same two percentage points come to 0.0355 BTC a year.

Why ranking pools on a single percentage still breaks is worked through in our piece on fees and a four factor pool score: the payout threshold, the network fee policy and the auto conversion spread beat the percentage gap more often than the percentage does.

What are luck and variance, and why can a pool fall short of expectation over a week?

Luck is the ratio of expected share cost to the shares actually spent on the blocks found, shown as a percentage. A value of 78% means the blocks cost the pool more work than expected, 130% that they cost less. Variance is the statistical spread that luck comes out of. Block discovery is a Poisson process, so deviation is unavoidable and shrinks only as the sample grows.

A useful property of the Poisson distribution: the standard deviation equals the square root of the expectation. Relative spread therefore falls with the square root of block count, not in proportion to hashrate.

By POOL BTC's calculation, at a network hashrate of 930.73 EH/s and 1,008 blocks per week:

The top row is the same 100 TH/s machine, mining solo: expected time to a block at a difficulty of 127.45 trillion is about 173 years, and the chance of finding one in any given week is roughly 0.011%.

The bottom row corresponds to Foundry USA. Per the ChainBulletin table for 08.09.2026 (reproduced in KuCoin's 10.09.2026 write up) the pool holds around 244.6 EH/s, about 27% of the network, with AntPool near 156 EH/s and F2Pool near 127 EH/s. The Nakamoto coefficient, the number of pools producing more than half of all blocks, stands at 3 per D-Central's report for the first half of 2026.

Two conclusions come out of that table. A perfectly honest 10 EH/s pool with zero incidents will close roughly one week in three below 70% or above 130% luck, and that is ordinary behavior for a random variable. At the same time, if you are on FPPS, none of this row applies to you, because you are paid a rate per share whether the pool finds a block or not. Luck on FPPS is the operator's metric, not yours.

The reverse holds too. A single week of luck proves nothing in either direction. A meaningful sample for arguing about a PPLNS pool's honesty starts at a quarter.

What happens when you disconnect: stale shares, reject rate, failover?

When the link drops, the ASIC keeps hashing against the last job it received, but there is nowhere to send the results, so that work is lost. Once the connection returns, shares against the outdated job are rejected as stale. Your accrued balance is untouched: it sits on the account waiting for the payout threshold. What you lose is current work, plus your position in the window if you are on PPLNS.

The reasons a pool rejects a share mean different things and are worth separating in your logs:

1. Stale, or job not found: the share arrived against a job that is no longer current. Usually networking, latency, or a new block on the network.
2. Low difficulty share: the hash did not reach your current target. Often a desync right after a vardiff change.
3. Duplicate share: the same nonce and extranonce2 combination submitted twice. A sign of a firmware problem or a controller glitch.
4. Above target: the header fails validation outright. Usually hardware pushed too far on overclock or temperature.

Each operator sets its own normal for rejects, and no industry threshold exists. AntPool calls under 1% normal and separately cites an average stale rate of 0.5% or lower. ViaBTC says within 3%. F2Pool calls roughly 2% a reasonable delayed share rate. Braiins and Luxor publish no numeric threshold.

By POOL BTC's calculation, every 2 percentage points of reject rate costs exactly what 2 percentage points of pool fee costs, since both come off the gross credit. For a 100 TH/s machine that is the same 0.000355 BTC per year. A pool at 2% with a bad route to its server loses to a pool at 3% with a stable one.

Which makes failover less optional than it looks. An ASIC's stratum configuration takes several pool addresses, and the firmware moves to the next one when the primary drops. Fill every available slot, and keep at least one backup on a different operator or at minimum in a different region, or both will fail at the same moment. Stock Antminer firmware has three slots (Pool 1, 2 and 3, per Bitmain support), and Whatsminer has the same three.

One detail specific to PPLNS: leaving a pool does not burn your shares as a penalty. They simply age out of the window as new work arrives. Ocean documents this explicitly, saying shares are never removed from the share log and merely stop counting once the volume of work pushes them past the window boundary. The practical effect is the same, but "the pool keeps your shares" is the wrong description.

How is a pool different from hosting and from cloud mining?

A pool is work coordination: the hardware is yours, sitting wherever you keep it, and the pool hands out jobs and pays for accepted shares. Hosting is a site: the hardware is still yours, but power, cooling and connectivity belong to someone else, and you still choose the pool yourself. Cloud mining is a contract: you own no hardware at all, only a counterparty's promise to pay you a stream.

Hosting plus a pool is a normal arrangement, and the two do not compete. Cloud mining sits apart because it removes the only verifiable link in the whole chain: the correspondence between your hardware, your shares, and coins in the blockchain. With a pool and with hosting that link survives, and you can recompute it yourself.

How to read pool terms when choosing, and what to look at besides the percentage, is covered in our comparison of 12 pools.

Frequently asked questions about mining pool mechanics

Can a pool steal a block it found and say nothing?

A block built from a pool's template carries a coinbase transaction with that pool's addresses and tag, and it shows up in any explorer. Hiding it is not possible. What genuinely cannot be checked from outside is the internal accounting: a specific miner's slice of a PPLNS window and the pool's real hashrate remain its own reporting.

Does share difficulty affect my income?

No. Share difficulty changes only the frequency and weight of submissions, and the product stays the same. Double the difficulty and you send half as many shares, each worth twice as much. It does affect statistical accuracy: too high a difficulty makes the hashrate chart for a small machine noisy.

Why does the pool dashboard show less hashrate than my ASIC?

Your machine reports instantaneous hashing speed while the pool estimates your hashrate after the fact, from accepted shares over an averaging window. They cannot match by construction. Rejected and stale shares widen the gap further, as does latency to the stratum server. Compare a daily figure to a daily figure.

What happens to my shares if I leave before the pool finds a block?

On PPS and FPPS, nothing: you were credited a rate for every accepted share and it already sits on your balance. On PPLNS your shares stay in the window and take part in blocks found after you leave, until new work pushes them past the boundary. Accrued balance does not burn, it waits for the threshold.

Why does the pool need my hashrate if it pays for shares?

It does not know your hashrate directly. The pool derives it from the share stream: accepted shares multiplied by their difficulty, divided by the length of the window. That is an estimate rather than a measurement, which is exactly why a five minute chart jumps around while a daily one looks smooth.

What remains unconfirmed in our data as of 24.09.2026

1. Fee percentages at Luxor and Foundry USA. Neither publishes a single number: Luxor calls its fee a discount to spot FPPS, Foundry prices by hashrate tier.
2. EMCD's payout threshold: the help center articles that should state it returned 404 on 24.09.2026.
3. Kryptex's 3% comes from our manual check of 29.08.2026; on 24.09.2026 the percentage did not show up in the text of its public fee pages.
4. Network parameters in the calculations above are a snapshot of 08.09.2026 (hashrate 930.73 EH/s, difficulty 127,450,789,715,843, mempool.space). On 24.09.2026 the same API showed 917.89 EH/s and a difficulty of 132,757,073,449,487, so a 100 TH/s machine now earns about 4% less subsidy per day than in the examples above. The next retarget at block 969,696 was estimated at about minus 5.5%.
5. Share difficulty values in the tables above are round powers of two, chosen to make the arithmetic legible. F2Pool, AntPool and Braiins do not publish default or minimum share difficulty. ViaBTC publishes the mechanism rather than a number: a d= parameter in the worker password sets the starting difficulty and md= sets the floor.

In short

A share is a block with a lowered bar, and nothing more. The pool picks the height of that bar to suit your machine, so it can see your work in real time, and the setting does not touch your income.

The pool builds the block, not you. Under Stratum V1 the miner receives Merkle branches and a coinbase stub, never a transaction list. That changes only under Job Declaration, and only a handful of pools run it in production.

A payout scheme answers one question: whose risk. PPS and FPPS sell you predictability through the percentage, PPLNS leaves the spread with the miners, SOLO averages nothing. Luck is the pool's metric, and on FPPS it never reaches your payout.

Reject rate costs precisely what the fee costs, because both come off gross credit. Two percentage points lost to connectivity eat the same amount as two percentage points of tariff, which is why a well connected pool at a higher rate often beats a cheap distant one.

This article contains referral links to mining pools (marked as sponsored). We may receive a reward if you register through them. This does not change the figures or the order of rows in the tables: the terms are taken from the pools' official pages.