A Mining-Pool Payout Promise Is Not an Accounting System

Disclosure: I operate BTC PoW Lab Pool, which is used below as a case study. This draft was prepared with AI assistance and reviewed against the live public API and project records. The pool has not found a block and has no payout history.

A percentage on a mining-pool landing page is not an accounting system.

“The finder receives 85%” sounds precise. It is not enough to answer the questions that appear after a real block:

• Which miners were eligible at the exact block height?
• Which accepted shares were inside the reward window?
• Was the finder excluded from the community allocation?
• How were rounding and dust handled?
• Which exchange rate produced the USD estimate shown in a screenshot?
• Can the operator reproduce the result after a restart or database restore?

If those answers are calculated from mutable live state, two honest queries made seconds apart can disagree. A restart can make the disagreement harder to explain. A screenshot can then look like stronger evidence than the database.

The fix is to treat the block as an accounting event and create an immutable snapshot.

Separate the economic identity from the connection

A miner may use several workers, reconnect repeatedly, or run more than one device. Those are operational sessions, not necessarily separate economic participants.

The payout identity should be the Bitcoin address or another explicit settlement identifier. Workers and sessions roll up into that identity. This prevents a participant from manufacturing additional reward weight by splitting one hashrate source into many worker names.

The raw events should still preserve:

• session ID;
• worker ID;
• payout identity;
• accepted difficulty;
• block height;
• server timestamp;
• job and extranonce identifiers;
• rejection reason, when applicable.

Aggregation should change the accounting view, not erase the evidence.

Freeze rules and inputs together

At block detection, the snapshot should capture more than the final totals. It should include the inputs needed to reproduce them:

{
  "block_height": 965350,
  "rules_version": "hybrid-solo-tiered-community-7d-v5",
  "eligibility_window_seconds": 604800,
  "finder_identity": "bc1q...",
  "finder_excluded": true,
  "network_reward_sats": 0,
  "allocations": [],
  "created_at": "2026-09-03T00:00:00Z",
  "input_digest": "sha256:..."
}

rules_version matters because software changes. Re-running today’s code against last month’s data is not necessarily a valid historical reconstruction.

An input_digest matters because it binds the snapshot to the accepted-work set used by the calculation. If a later audit imports events from backup, the digest can establish whether it reconstructed the same input.

Account in satoshis, display in fiat

Settlement amounts should be integers in satoshis. Fiat values are presentation-layer estimates.

A user may capture “US$ 120.20” and see “US$ 117.80” later even when the underlying reward remains exactly 158,323 sats. That is normal if the BTC/USD quote changed. The interface should show both values and explain which one is authoritative.

For every allocation, persist:

• exact total_sats;
• allocation components;
• remainder policy;
• dust state;
• fiat quote and quote timestamp used for display;
• status such as PROJECTED, FROZEN, PAYABLE, DEFERRED_DUST, BROADCAST, or CONFIRMED.

Never overwrite the satoshi amount merely because the display quote changed.

Make rounding deterministic

If proportional weights do not divide the reward exactly, the system needs a published remainder rule. Examples include largest remainder or deterministic assignment ordered by a stable identity hash.

The important part is not which reasonable rule is selected. The important part is that the rule is versioned, deterministic, and applied before the snapshot is sealed.

The sum must satisfy an invariant:

finder_sats + community_sats + lab_sats + explicit_remainders
  = distributable_block_reward_sats

If the invariant fails, payout preparation must fail closed.

Calculation and signing are different trust boundaries

An automatic calculator does not need access to private keys. A signer does.

That difference is operationally important. A safer pipeline is:

1. detect a candidate block;
2. verify it against the Bitcoin node;
3. freeze the accounting snapshot;
4. wait for the configured confirmation threshold;
5. construct a batch transaction or PSBT from the frozen plan;
6. validate outputs against the snapshot;
7. sign in a separate, constrained environment;
8. broadcast and record the transaction ID;
9. reconcile every output and fee.

This is also where “automatic payouts” can become custody. If community funds first arrive at an operator-controlled address, the operator controls those funds until the distribution transaction is signed. Automation reduces manual work; it does not remove the custody boundary.

Design the appeal process before the dispute

Suppose a miner says, “I should have received more,” and sends a screenshot.

The operator should be able to produce an audit bundle without editing the production database:

• block and confirmation evidence;
• rules version;
• participant identity and eligibility interval;
• accepted-work rows or a verifiable aggregate;
• weight calculation;
• exact satoshi allocation;
• fiat quote metadata;
• snapshot digest;
• payout transaction and reconciliation state.

The screenshot is then useful context, not the sole source of truth. It may reveal a stale UI, a changed exchange rate, a different worker aggregation, or a real accounting defect.

Survive restarts and machine loss

The snapshot and event journal should not live only on the machine running Stratum.

A practical minimum is:

• an atomic local snapshot;
• an encrypted off-site copy;
• a manifest containing hashes and schema versions;
• a restore test on a separate path;
• documented recovery-point and recovery-time objectives.

“Backup completed” is weaker than “backup downloaded, decrypted, hashed, and restored successfully.” Verification is part of the backup.

What transparency can and cannot prove

Before its first block, a pool can prove that its rules are published, its telemetry exists, its snapshot code is deterministic, and its backups restore.

It cannot prove a successful payout history that does not exist.

That distinction is healthy. Engineering evidence should make future claims testable without turning preparation into a claim of completed performance.

The BTC PoW Lab Pool accounting model and live limitations are public here:

• Accounting model
• Operational status

The broader lesson applies beyond mining: if money is distributed from changing state, freeze the rules, freeze the inputs, record exact units, and separate calculation from signing.