How pools work: shares, the payroll ledger

Your pool needs to know how much work you did, but blocks arrive rarely and only one miner wins each. The solution: you mine the pool's block templates at a much lower difficulty than the network's. A share is any hash that clears that easier bar — a result that would have been a block if it had met the full network target.

Every share is a losing ticket that proves you bought tickets. Millions per block, each timestamped and attributed to your account, become the pool's payroll ledger. When the pool lands a block, that ledger decides the split — the payout scheme (its own lesson) decides the exact rule.

The protocol tying your miner to the pool is stratum. It does exactly two jobs, both latency-sensitive: the pool pushes jobs (new block templates to hash on — issued whenever the chain moves, a transaction set updates, or the pool rebalances), and your miner submits shares back. Everything else — subscriptions, difficulty updates, stats — rides the same channel.

This is why mining latency has a narrow blast radius (the stale-shares lesson quantifies it): only job delivery and share submission are time-critical, measured in tens of milliseconds of tolerance, while the heavy lifting — the hashing — happens entirely on your machine.

The pool sets how hard a share must be, and auto-tunes it (vardiff):

• Too easy → your miner submits a firehose of shares, wasting both sides' bandwidth and the pool's bookkeeping.
• Too hard → shares arrive rarely, your accounting gets lumpy, and small hiccups look like outages.
• Just right → a steady trickle (roughly one share every few seconds) with minimal overhead.

Manual share-difficulty overrides exist for diagnostics, not earnings — shares measure you, they don't pay you differently. Leave vardiff on unless you know why you're touching it.

Pool cards on project pages show live workers and hashrate — the aggregate of everyone's share streams — and per-block data shows the moments a round ended and a new job went out.