Quick answer
Your pool’s payout method quietly decides your earnings. FPPS pays a steady rate including transaction-fee revenue (low variance, most popular); PPS pays the block subsidy only; PPLNS rewards loyalty and swings with luck but resists pool-hopping; TIDES pays transparently from the coinbase, non-custodially. Weigh fees, variance, and custody risk — don’t just join the biggest pool. Your hashrate is your vote.
Short answer: compare a payout arrangement in three layers: what value a valid block contains, how submitted work is credited, and how an account balance becomes a payment. Similar labels can conceal different reward bases, windows, exclusions, charges, custody arrangements, and template policies.
Three Layers That Must Not Be Mixed
| Layer | Question | Evidence |
|---|---|---|
| Protocol block value | What did a valid block create and collect? | Coinbase transaction, included transactions, active-chain status, and consensus rules. |
| Share ledger and allocation | How does the contract turn credited work into an obligation? | Jobs, share targets, accepted difficulty, reason codes, formula version, window or score, and eligible block events. |
| Settlement | How does an obligation become spendable funds? | Title and custody terms, threshold, cadence, address, withdrawal charges, transaction identifier, outputs, and confirmations. |
Bitcoin’s block incentive consists of the permitted subsidy and transaction fees from included transactions. A pool share is normally an easier proof used for accounting, not a Bitcoin-valid block. A reward formula can be transparent while settlement remains custodial, delayed, conditional, or separately charged.
Glossary for Reproducible Accounting
- Network difficulty
- A representation of the proof required for a Bitcoin-valid block at that time.
- Share target and share difficulty
- A service-assigned threshold and its difficulty representation, used to measure submitted work. Variable-difficulty systems can change it over time.
- Accepted and credited
- Accepted means the service recognized a submission under its protocol. Credited means the contract gave that submission a stated accounting weight; verify whether the terms distinguish them.
- Rejected, stale, duplicate, and low-difficulty
- Reason categories whose definitions and payment treatment belong in the contract and export. A late submission can be stale even when the underlying work was performed.
- Round, window, score, and shift
- Implementation-specific boundaries or weights. The unit may be time, shares, accumulated difficulty, block events, or another published rule.
- Distributable value
- The block-derived or quoted amount remaining after only those inclusions and deductions stated in the formula.
- Coinbase maturity
- A consensus delay before a coinbase output can be spent; it is separate from a service’s payout threshold and chain-risk policy.
Measure Credited Work Before Estimating Value
For each submission i, let a_i be the credited fraction, d_i its share difficulty on a consistent difficulty-one basis, D_i the applicable network difficulty, and Δt the measurement interval. Preserve target changes and reason codes instead of relying only on a dashboard hashrate.
Credited work: W = Σ(a_i × d_i)
Approximate hashrate: H_est ≈ W × 2^32 ÷ Δt hashes per second
Expected valid blocks represented by the work: E[N] ≈ Σ(a_i × d_i ÷ D_i)
The hashrate conversion uses Bitcoin’s conventional difficulty-one reference and is an estimate over a stated interval. It does not prove future availability, pool credit, a valid block, or payment.
Expected Value Is a Worksheet, Not an Earnings Claim
For each interval, define R_i as the contract’s quoted or distributable reward base, after only the inclusions and deductions that the contract says are already embedded. A method-neutral expectation is:
EV_contract ≈ Σ[(a_i × d_i ÷ D_i) × R_i]
EV_cash = EV_contract − only charges and adjustments not already included in R_i
Do not add estimated fees to a quote that already includes them, or subtract an operator charge already embedded in R_i. Map every term once to the dated formula, then reconcile separately stated settlement, withdrawal, conversion, and tax-related records. For a block-contingent window, a participant’s illustrative allocation is:
credit_j = distributable block value × w_j ÷ Σ(window weights)
The contract must define w, the window boundary, eligible block events, rounding, and deductions. Raw share count is not interchangeable with credited difficulty when targets differ.
Comparison of Payout-Accounting Families
| Label or family | Common trigger | Common reward basis | Block-arrival variance | What the label does not establish |
|---|---|---|---|---|
| PPS | Credited share | Contract quote per unit of work | Shifted toward operator while the obligation is honoured | Whether fees are included, quote revision, invalid-block adjustments, custody, or settlement. |
| FPPS | Credited share | Commonly subsidy plus an estimated or averaged fee component | Shifted toward operator | Fee data source, averaging period, out-of-band revenue, deductions, or reconciliation. |
| PPS+ | Mixed | Commonly a per-share subsidy component plus a block-contingent fee component | Split by component | Score or window formula, fee attribution, startup and exit effects, or settlement. |
| PPLNS | Eligible block event and prior eligible work | Contract-defined distributable block value | Retained by window participants | What N measures, weights, boundary events, invalid-block handling, or tail behaviour. |
| TIDES label | Only as stated in dated operator terms | Unverified without auditable terms | Do not infer from label alone | Expansion, index parameters, settlement, custody, or payment mechanics. |
| Solo boundary | Miner’s own valid block under the service contract | Contract-defined block value | Retained by miner | Template control, service charge, coinbase destination, custody, or block-validity handling. |
Label caveat: these are common descriptions, not standards. “Solo” is included only as a boundary: there is no inter-miner reward allocation, even if a service supplies work, relay, or accounting.
What Each Label Commonly Means—and Does Not Promise
PPS family
A textbook PPS calculation values credited work without waiting for the operator’s pool to find a block. A compact representation is credit_i = q_i × a_i × d_i ÷ D_i × R_i, where the contract must define quote factor q_i and reward base R_i. The formula shifts block-arrival variance; it does not remove counterparty or calculation risk.
FPPS label
FPPS commonly adds a fee estimate to a per-share quote. “Full” is not a protocol term. Record the fee data set, observation and payment windows, estimator, exclusions, treatment of unusually large or out-of-band payments, operator charge, and whether later reconciliation occurs.
PPS+ label
PPS+ commonly mixes components: a per-share subsidy-related credit and a realized-fee allocation associated with eligible blocks. The second component may use a score or window, but the label does not select one. Audit each component separately.
PPLNS family
Pay-per-last-N-shares is block-contingent. N may represent credited shares, difficulty, time, shifts, a score, or another unit. Joining, leaving, outages, target changes, and window replacement can alter realized timing. A window can reduce some hopping incentives, but no label makes strategic behaviour impossible.
TIDES label
No neutral, durable public primary specification was retained for this label in this edition. It is therefore not treated as a standardized accounting family. Obtain a dated operator formula, index definition, reward base, settlement terms, and export before making any claim about its accounting or custody properties.
Variance Transfer and Counterparty Exposure
Independent valid-block discoveries are often modelled with a Poisson approximation: for expected count λ, E[N] ≈ λ and Var[N] ≈ λ. This is a model for discovery variance, not a payment promise. PPS-family accounting can make a miner’s short-window ledger smoother by placing that variance and reserve requirement on the operator. Window and score methods leave more event timing with participants.
Every method leaves other uncertainty: service outages, invalid or withheld work, stale and reject treatment, formula changes, fee-estimation error, reserves, default, custody, withdrawal restrictions, address error, legal process, and chain events. “Lower variance” must always identify which variance, over what interval, and for whom.
Risk Register and Evidence Controls
| Risk | Control evidence | Reconciliation question |
|---|---|---|
| Reserve or default | Current legal counterparty, obligation wording, reserve or assurance evidence, change history | Who owes what, when, and under which remedy? |
| Custody and withdrawal | Title terms, threshold, cadence, address controls, withdrawal and network charges | When does ledger credit become an on-chain output controlled by the miner? |
| Rejected or stale work | Timestamped job/share export, target history, reason codes, clock and network logs | Was each exclusion consistent with the archived rule? |
| Outage and failover | Status history, client logs, failover configuration, duplicate-work rules | Was work lost, redirected, duplicated, or credited? |
| Invalid block or chain event | Block identifier, validation result, active-chain status, maturity and contract policy | Which event triggers credit, reversal, delay, or no credit? |
| Formula or fee change | Dated terms, notice, effective timestamp, archived estimator and charge schedule | Which version applied to each share and settlement? |
| Template and transaction policy | Job source, template policy, declaration capability, coinbase destination, revenue scope | Who chose transactions and who received all block-related value? |
| Legal and records | Entity, jurisdiction, dispute terms, exports, invoices, valuation source, retention plan | Can the result be reproduced for a dispute or filing? |
Template, Accounting, and Settlement Capabilities
| Role | Possible capability | Does not automatically imply |
|---|---|---|
| Hashing device | Search candidate headers and submit shares | Transaction selection, validation, accounting, or custody |
| Proxy or mining client | Distribute jobs, aggregate channels, declare supported jobs | Ownership of the payout obligation |
| Template constructor | Select a valid candidate transaction set and coinbase structure | Share accounting or final settlement |
| Pool accountant | Validate submissions and apply a reward formula | Direct coinbase payment or miner-selected templates |
| Payout service or custodian | Hold balances and create withdrawals | Block construction or independent validation |
| Fully validating node | Enforce its configured consensus rules | Finding blocks, receiving rewards, or deciding another party’s template |
Modern mining protocols can support miner-declared jobs while a pool continues to account for shares. Ask who supplies each job, who can change the transaction set, how out-of-band value is treated, who controls coinbase outputs, and what happens when a declared job is rejected.
Contract Due-Diligence Worksheet
- Archive the exact terms URL, version, effective time, legal entity, governing law, and change-notice rule.
- Copy the full formula, rounding rule, currency/unit, reward base, quote source, fee estimator, and observation window.
- Record share target and vardiff history; accepted, credited, rejected, stale, duplicate, and low-difficulty definitions; and every reason code.
- Define round, score, shift, N or index units; eligible block events; invalid-block and active-chain treatment; and startup/exit tail.
- Separate operator percentage, reward-base exclusions, withdrawal charge, network charge, conversion spread, and minimum threshold.
- Document payout cadence, destination controls, custody/title, coinbase destination, maturity policy, and evidence of final settlement.
- Identify reserve/default assurances, outages and failover treatment, dispute procedure, API/export retention, termination, and account restrictions.
- Identify who constructs templates, whether job declaration is supported, transaction policy, treatment of out-of-band value, and publication evidence.
- Confirm tax documents, timestamps, time zone, valuation source, record-retention period, and qualified local advice.
Synthetic Payout Reconciliation
Use fictional units to test the contract before relying on a dashboard. Suppose an export contains changing share targets and 100 normalized units of submitted work. First remove only submissions excluded by the archived rule and record every reason code. Sum credited difficulty rather than raw share count. Apply the network difficulty and reward-base inputs that were valid for each interval, then reproduce the operator’s formula, rounding, and window.
- Verify job identifiers, target changes, timestamps, and worker identity.
- Recalculate accepted and credited difficulty and list every rejected unit.
- Identify the exact formula version effective for each interval.
- For block-contingent methods, verify eligible block identifiers, active-chain outcome, window boundary, and participant weights.
- For quoted methods, verify the quote and any fee-estimation source or later adjustment.
- Reconcile operator, withdrawal, network, or conversion charges as distinct lines.
- Match the resulting ledger obligation to the payout record and on-chain transaction output.
- Retain the export, calculation, contract, correspondence, and valuation evidence together.
This normalized example is not a forecast. Changing the formula, share-acceptance policy, time window, network conditions, operator solvency, or settlement terms changes the outcome.
Records, Legal Terms, and Tax Boundaries
Pool participation can create contractual, custody, sanctions, reporting, and tax questions that differ by entity, residence, business facts, and payment path. Do not infer deductibility or legal treatment from a method label. Keep contemporaneous source records and use current official guidance and advice qualified for the relevant jurisdiction.
Related Educational Guides
- Pool versus solo architecture and variance
- Solo mining mechanics and probability boundaries
- Nodes, miners, pools, and validation roles
- Hashrate and accepted-work measurement
Primary Sources and Revision Record
- Bitcoin whitepaper, sections 4 and 6 — proof-of-work probability and the subsidy-plus-fees incentive.
- BIP 22 pinned at repository revision 7fe0b03 — block-template and fee-accounting fields.
- Stratum V2 Mining Protocol pinned at revision 0f38d51 — channel targets and share submission/accounting messages.
- Stratum V2 Job Declaration Protocol at the same revision — separation of job declaration from pool accounting.
- Analysis of Bitcoin Pooled Mining Reward Systems, arXiv:1112.4980v1 — variance, proportional, score, and window-system analysis.
- Hardening Stratum, Proceedings on Privacy Enhancing Technologies 2017 — jobs, share targets, accepted/rejected submissions, and stale work.
- TIDES is scoped as an unverified operator label until dated, auditable terms are supplied; no public provider attribution is made.
- Canadian tax authority crypto-asset records guidance, reviewed 2026-08-29 — mining, pool, expense, and activity records.
Content revision: 2026-08-29. Protocol repository links above are pinned to the displayed commits; the whitepaper and research paper are fixed publications. Web guidance should be rechecked before relying on changed implementation or legal terms.
Frequently Asked Questions
Does PPS or FPPS guarantee that I will be paid?
No. A PPS-family contract can shift block-arrival variance to its operator, but payment still depends on the exact formula, share acceptance, service availability, reserves, solvency, custody, and settlement terms. Archive the contract version and reconcile credits rather than treating a method label as a guarantee.
Does PPS always exclude transaction fees?
No. PPS describes payment for credited work without waiting for the pool to find a block; it does not universally define the reward base. The contract must say whether its quote uses subsidy only, subsidy plus a fee estimate, another reference amount, or later adjustments.
What is the difference between FPPS and PPS+?
Common usage treats FPPS as a per-share quote that includes a contract-defined fee estimate, while PPS+ commonly combines a per-share subsidy component with a block-contingent fee component. Neither label standardizes the estimator, window, score, deductions, or settlement process, so compare formulas rather than names.
How does a PPLNS window affect joining or leaving?
A PPLNS credit is commonly based on eligible work inside a contract-defined lookback when an eligible block event occurs. Joining can begin with little work in the window, and prior work can remain until it ages out after leaving. The unit of N, weights, boundary events, and startup or exit treatment must be read from the contract.
What does a TIDES label establish?
Treat TIDES as a contract-defined label unless the operator supplies dated, auditable technical and settlement terms. This guide does not independently verify an expansion, index parameters, payout threshold, cadence, coinbase destination, custody, or withdrawal mechanics from the label alone.
Why is share difficulty different from network difficulty?
Network difficulty represents the proof required for a Bitcoin-valid block. A pool can assign an easier share target to measure contributed work. The share difficulty, applicable network difficulty, accepted-work rules, and vardiff history are separate fields needed to reproduce an accounting result.
How can I verify stale or rejected shares and a payout?
Export timestamped jobs, share difficulty, acceptance status, reason codes, and the applicable contract version. Reconcile credited difficulty to the formula, any block or fee inputs, operator and settlement charges, the pool ledger, and the final transaction identifier and output. A dashboard total without an export is weak dispute evidence.
What records should I retain for tax reporting or a dispute?
Keep dated contract versions, wallet and payout records, share and job exports, invoices, operator and withdrawal charges, transaction identifiers, timestamps and time zones, valuation sources, equipment and energy records, and correspondence. Retention and tax treatment depend on jurisdiction and facts, so use current official guidance and qualified advice.
