Why is my mining pool payout lower than expected?
Check three separate stages: work the pool accepted, rewards credited under its calculation rules, and money actually sent to your wallet. A machine can be running while submitting less accepted work than expected. A pool balance can grow without reaching the withdrawal threshold. Neither situation is explained by looking only at the hardware’s advertised hashrate.
This guide is a worksheet for reading pool records, not a recommendation to buy equipment or join a particular pool. If mining itself is new to you, start with the overview. Here, the goal is to locate a discrepancy before changing settings or assuming that a dashboard estimate is spendable income.
What is a mining share?
A share is evidence of hashing work that meets a pool’s assigned target. That target is normally easier than the network target for a block. Shares let a pool account for contributors even though most submitted shares do not produce a block. They are not shares in a company and are not coins that you can withdraw.
Keep the target in mind when comparing logs. If the assigned share difficulty changes, ten shares at one difficulty do not necessarily represent the same amount of work as ten at another. Use the pool’s work accounting or effective hashrate where appropriate, rather than comparing unqualified share counts between miners.
PPS, FPPS, PPLNS and PPS+: what changes?
Pay Per Share, or PPS, credits qualifying work using a calculated per-share reward instead of waiting for your pool to find a particular block. Full Pay Per Share, or FPPS, also includes a calculated transaction-fee component. Read how that component is estimated and which fee the operator deducts.
Pay Per Last N Shares, or PPLNS, allocates rewards from blocks the pool actually finds using eligible work in its defined share window. Pool luck therefore affects short-period rewards. A machine operating steadily does not imply the same daily reward.
PPS+ combines a PPS-style subsidy component with a transaction-fee component based on the pool’s actual results using PPLNS-style allocation. These are broad method descriptions; a provider’s precise window, fee calculation and eligibility rules matter.
No method fixes the coin’s price, future network difficulty or your expenses. More predictable reward accounting does not remove the risk of relying on a pool operator. Compare the same coin, work period and included reward components before comparing two advertised percentages.
Why does the pool show less hashrate than the miner?
The local device reports its own hashing activity; a pool estimates effective hashrate from submitted work over a time window. Braiins documents both share variance and connection stability as reasons the figures differ. A short dip is not enough evidence of hardware failure.
Compare matching periods, worker identifiers and uptime. f2pool recommends comparing a 24-hour average rather than a brief snapshot. If one screen covers the last five minutes and the other covers a full day containing downtime, they are measuring different periods.
In your own worksheet, record the miner’s start and stop times, the pool’s reporting timezone and any reconnects. Keep advertised nominal performance in a separate column. This prevents a specification-sheet number from being mistaken for measured, accepted work.
What are stale or rejected shares, and what should I check?
A pool can reject submitted work instead of crediting it. f2pool identifies latency and work arriving for an already-mined block as common causes. “Stale” commonly refers to work that arrives too late for the current job. Read the rejection reason and the pool’s treatment of that reason; dashboards do not all categorize work identically.
First inspect connection stability and the configured endpoint against the pool’s official instructions. Then compare worker logs, timestamps and the manufacturer’s supported firmware guidance. Do not increase voltage or disable protections merely to make a dashboard number look better.
If rejection increases after a change, record that change and compare an equivalent period. A local connection problem and a pool-wide incident require different investigation. Give support the relevant timestamps and error codes, with credentials and private network details removed. There is no universal rejection percentage that proves every setup is healthy.
Worked log: accepted work, fees and a payout threshold
Consider an invented daily log with 980 accepted shares and 20 rejected shares. Assume all 1,000 shares have equal difficulty and the two categories are exhaustive. The rejection rate by count is 20 ÷ 1,000 = 2%; the acceptance rate is 98%. Do not carry that count formula into a mixed-difficulty log without checking how work is weighted.
Now suppose the pool’s reward calculation for the accepted work produces 10,000 satoshis before an illustrative 2% pool fee. The fee is 200 satoshis and the net credit is 9,800. The accepted work is already reflected in that gross reward, so subtracting another 2% for rejected shares would double-count the rejection effect in this example.
If the opening balance is 43,000 satoshis, the new balance is 52,800. With a hypothetical 50,000-satoshi threshold, it clears that threshold. This does not prove a transfer has been sent: the schedule, account conditions and any withdrawal fee still need checking. These numbers are invented, not current pool rates or a mining revenue forecast.
A reward balance and a wallet payout are different records
Braiins documents separate reward calculations, payout rules, thresholds and on-chain or Lightning destinations. Use your provider’s current settings rather than copying a threshold from an old tutorial. A balance below a configured threshold can explain why a wallet has not yet received a transfer.
Reconcile opening balance plus credits minus withdrawals and other recorded adjustments to the closing balance. For an on-chain transfer, compare the payout record with its transaction identifier and the independently verified destination. For Lightning, use the relevant payment status and reference; an on-chain transaction ID is not the right evidence for every payment route.
Finally compare what you received with energy and other expenses over the same period. Pool accounting can explain the coin amount while leaving the operation unprofitable. Our electricity worksheet covers that separate calculation.
Five-minute practice: identify what is missing
An operator shows a 100 TH/s machine label, one five-minute pool reading of 92 TH/s and an unpaid balance of 48,000 satoshis. Their payout threshold is 50,000. Can you conclude that the pool is taking 8% of their earnings? No: those observations do not establish a fee or a lost reward.
The supported conclusion is that the shown balance is below the stated threshold. To investigate the hashrate gap, request a matching longer-period device and pool history, uptime and accepted/rejected work. To evaluate deductions, obtain the reward-method calculation and fee entries. Keep each question attached to the record that can actually answer it.
Sources & further reading
- Bitcoin developer guide: pooled work and shares
- f2pool: PPS, PPLNS, FPPS and PPS+ definitions
- Braiins: nominal and effective hashrate
- f2pool: accepted work, rejection rates and monitoring
- Braiins: current reward calculation and payout rules
- f2pool: why PPLNS rewards fluctuate
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.