Why we say "pending mining reward", not "balance"

01 What the figure actually is

Every pool dashboard has a number near the top that miners watch. On most pools it is labelled "balance". Here is what it is made of, step by step, using Spearmint Mining's rules.

1. The pool finds a block. Its coinbase transaction creates the block reward, 50 SPMTC at launch plus the block's transaction fees, paid to the pool's operational address. That output cannot be spent until the block has 100 confirmations, about 50 minutes at the 30-second target.
2. The pool runs its reward calculation. Under PPLNS it looks back over the most recent shares whose summed difficulty equals twice the network difficulty, takes the 1% pool fee off the reward, and apportions the remainder across the addresses that submitted those shares in proportion to share difficulty.
3. Each address's portion is written to a table of reward allocations: block, address, share weight, gross, fee, net.
4. The sum of an address's net allocations from blocks that have matured and have not yet been paid is the figure on the dashboard.

So the number is a sum of rows in an allocations table, each row tied to a specific block and a specific set of shares. It is derived from mining, it is verifiable from the block list and the exportable share logs, and it exists for one purpose: to be paid out at the next run. It is an accounting estimate of rewards awaiting distribution. That is a mouthful, which is why "balance" is tempting. It is also wrong, for reasons the next two sections cover.

02 Why it can go down

A balance, in ordinary usage, is something you have. It goes down when you spend it. The pool figure goes down for a reason that has nothing to do with the miner.

When two miners find competing blocks at the same height, the network keeps one and orphans the other. If the pool's block is the orphan, the coinbase reward in it never becomes spendable; from the chain's point of view it was never paid. Every allocation the pool wrote against that block has to be reversed. On a chain with 30-second blocks and per-block difficulty retargeting, orphans are not rare events, and the pool's own risk register records reorg pressure as an open question rather than a solved one.

This is also why nothing is distributed before maturity. A pool that paid out on unconfirmed blocks and then saw one orphaned would have sent coins it did not have. Waiting for 100 confirmations means the allocation is confirmed before it is paid; until then it is pending in the literal sense.

03 Why the word matters

Words on an interface are not decoration. Three audiences read them and act on them.

Miners

"Balance" tells a miner they have something stored at the pool that they can take out. It invites the questions "how do I withdraw?", "can I send it to a friend?", "why can't I have it now?" — every one of which describes a service this pool does not offer. "Pending mining reward" tells them what it is: a reward, from mining, that is pending. The next question is "pending until when?", and the answer is on the tile.

Regulators and counsel

FinCEN's 2019 guidance on mining pools draws its line at hosting wallets on behalf of members, which it calls "account-based money transmission". A dashboard that says "account", "balance", "deposit" and "withdraw" describes an account-based relationship in the operator's own words, whatever the software does underneath. Pennsylvania's Act 7 of 2025 asks whether the operator transmits virtual currency "on behalf of an individual"; a "withdraw to address" button is the cleanest possible illustration of doing exactly that. Using mining words is not a way to hide a custodial service. It is a way to describe a non-custodial one accurately, and to make sure the description and the software say the same thing. If they ever diverge, the software is what counts, and the change-control document exists to stop it diverging.

Developers

Vocabulary becomes schema. A team that talks about balances writes a balances table. A balances table acquires a transfer() function, because moving a number between two rows is the obvious thing to do with a balances table. Now the pool has user-to-user transfers, which is a different regulated business, and nobody decided to build it. Spearmint's data model has no balances table. It has reward_allocations, whose only money-like column is net, and whose rows exist to be summed into a payout. The word on the dashboard and the name of the table agree.

04 How the dashboard is labelled

The terminology page is the reference. The short version:

The pending-reward tile always carries this text, in the tile and not behind a tooltip:

Amounts are shown in SPMTC only. There are no fiat conversions anywhere in the interface, because a dollar figure next to a pending reward reads as a claim about value, and the pool makes no such claim.

05 The threshold's one legitimate purpose

If the figure is not a balance, why is it not paid the moment it matures? Because a payout is an on-chain transaction, and every output in it costs a network fee. Paying 0.004 SPMTC to four thousand addresses every hour would spend more in fees than it delivered and bloat the chain doing it.

So Spearmint Mining runs one payout per day, at 00:00 UTC, batched into a single transaction with one output per address, and includes any address whose mature pending reward is at least 1 SPMTC. The network fee is deducted from the batch pro rata and shown against each payout. The threshold is fixed, not miner-adjustable, on purpose: a miner-set threshold is a savings preference, and a savings preference is what an account has.

That is the whole justification. The threshold exists so that distributions are operationally practical. It is not a holding period, it is not a way to keep float, and it is not described anywhere as coins "stored" for the miner. The Mining Reward and Payout Policy says this in its own words, and the question of how long a pool may hold mature allocations before it starts to look like an account is listed for counsel on the review page rather than assumed away.

06 The inactive sweep

A threshold has one obvious failure mode: a miner who stops with 0.7 SPMTC pending would never reach it, and the pool would hold that 0.7 SPMTC forever. Over thousands of miners that is a growing pile of value belonging to people who have left, which is precisely the thing the design is meant not to have.

The rule that closes the gap: if an address has submitted no shares for 30 days, any mature pending reward above the network dust limit is paid in the next run regardless of the threshold. The pool sweeps itself clean of departed miners' rewards. Nothing accumulates. Rewards below the dust limit cannot be paid on-chain at all, and what happens to those is one more question on the counsel list, not a silent policy.

Put the three rules together — pay only mature rewards, pay daily above 1 SPMTC, sweep inactive addresses after 30 days — and the longest an allocation can sit with the pool is bounded and stated. That is what makes "pending" the right word. It is pending a specific event on a specific schedule, and then it is gone.

07 Key takeaways

• A pool's unpaid figure is a sum of reward allocations tied to specific blocks and shares, not coins in an account.
• It can decrease: if a block is orphaned before 100 confirmations, allocations from it are reversed, which is why nothing is paid before maturity.
• "Balance", "deposit" and "withdraw" describe an account-based relationship; FinCEN's mining-pool guidance draws its line at exactly that, and vocabulary tends to become schema.
• Spearmint Mining labels the figure "pending mining reward" with a standing explanation in the tile, shows SPMTC only, and has no balances table.
• The 1 SPMTC daily threshold exists solely because on-chain payouts cost fees; it is fixed, not miner-adjustable.
• A 30-day inactive sweep pays out departed miners' rewards above dust, so nothing accumulates with the pool.

08 Questions

09 Sources

1. FinCEN, Application of FinCEN's Regulations to Certain Business Models Involving Convertible Virtual Currencies, FIN-2019-G001, 9 May 2019, §4.2 and §5.4. fincen.gov
2. Pennsylvania General Assembly, Senate Bill 202 (2025), enacted as Act 7 of 2025. palegis.us
3. Bitcoin Core, COINBASE_MATURITY (100 blocks) in src/consensus/consensus.h. github.com/bitcoin/bitcoin
4. Spearmint, Mining Reward and Payout Policy, Terminology, Architecture and value flow.