Stale Rate is the proportion of events or weighted work classified as stale within a precisely defined set. This entry primarily concerns mining pool shares that arrive or are processed in an outdated mining-job context.
On SetNewPrevHash, Stratum V2 requires switching to the new previous hash; only the referenced job_id remains valid among prepared jobs. Finding a hash below the earlier target alone therefore does not guarantee usability for current work. Diagnosis needs job context and changes, not just submission time. [Stratum V2 — Mining Protocol]
Illustration: of 100 equal-difficulty submissions, 98 are accepted, 1 rejected as stale and 1 for another reason. Rejected-stale proportion is 1%, while total rejection rate is 2%. This explains different numerators, not an acceptable operating threshold. F2Pool defines rejection rate against all submitted shares. [F2Pool — Rejection and Staled rates]
Braiins converts a share of difficulty d into d base units of work. If an illustration contains one stale share at difficulty 1 and one accepted at difficulty 9, the count-based proportion is 50% but the weighted proportion is 10%. Both numerators and denominators being compared must use the same unit and difficulty convention. [Braiins — Share difficulty accounting]
F2Pool documentation distinguishes paid “Staled” shares from rejected stale shares that generate no reward. This policy cannot be generalized to every pool. Before converting a percentage into lost income, check the actual category, acceptance rules and settlement; the metric name is insufficient. [F2Pool — Rejection and Staled rates]
Stratum V2 allows batched SubmitShares.Success. The new_submits_accepted_count field gives newly acknowledged submission count, while new_shares_sum gives their difficulty sum. Server response count therefore does not equal accepted share count. SubmitShares.Error carries sequence_number and error_code; without distinguishing reasons, not every error can be called stale. [Stratum V2 — Mining Protocol]
BIP152 covers Compact Block Relay between P2P nodes, not pool share accounting. Reduced data transfer may affect block delivery latency, but supplies no miner Stale Rate by itself. A network proportion of competing blocks cannot be used as the proportion of late submissions by a particular worker. [BIP152 — Compact Block Relay]
Braiins monitoring distinguishes shares_5m, shares_60m and shares_24h. Use the same time window and worker scope in numerator and denominator of your own ratio. Zero observed submissions do not constitute a measured 0% loss; the ratio is undefined. Missing responses or monitoring gaps do not automatically belong in the stale category. [Braiins — Worker monitoring windows]
F2Pool links stale work to network conditions but mentions firmware errors and overclocking for other rejections. Braiins distinguishes server reachability testing from actual performance. Examine job logs, rejection reasons and connections in the same period; ping alone or a lower aggregate percentage does not prove the cause has been removed. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]
For the clearest picture, read this entry together with Mining Share, Share Difficulty, Mining Latency, Pool Fee. The reverse links also lead from Mining Latency, Mining uptime.